Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Mercury Thirteen via Freedos-user]

On Saturday, March 28, 2020 6:34 AM, Eric Auer e.a...@jpberlin.de wrote:

> Hi Mercury, some short answers :-)
> I think dates as version numbers are fine when there is no explicit version 
> numbering. I would use the date of the most recent file, leave the decision 
> to you whether that means the version is this week since YOU yourself have 
> made per-driver excerpts of the readmes. Otherwise, use the newest timestamp 
> of the original files, even in situations where only documentation updates 
> took place.

Personally, I would like to assign a new version date to my packages since I've 
made some significant changes... however, I think that also would cause 
unnecessary confusion to existing users of these programs. E.g. "Sweet, a new 
version! Oh, wait... this is the same binary I already had. :(( " So I guess 
I'll leave the versions as-is.

> Regarding sources, please always use source\NAME\FILE.EXT naming. It is no 
> problem to have separate copies of CC in source\uide\cc.asm and 
> source\uhdd\cc.asm when installed. There is an official howto for the 
> directory tree etc. in ZIP files for install friendly packages, somewhere 
> online.

Yep, I think the place to which you're referring is 
[here](http://wiki.freedos.org/wiki/index.php/Package), a page I already knew 
about. Had I just read a little further, I would have seen the answer to this 
problem! lol

> Having two himemx variants to compare sounds like Japheth hopes to get MANY 
> TESTERS so a new update can consolidate into one version again? Or maybe a 
> command line option to pick one of the two styles now represented by two exes?

I think it's to give users a choice, depending on their needs. He mentions they 
both employ a different strategy of allocating blocks - perhaps one is 
First-Fit and another is Best-Fit - and each strategy would work better for 
different users. So he gave them a choice. But Idk, that's just my take on it. 
:)

> I suggest that you give Jerome a signal when you think the packages on your 
> website have been updated to fix all items mentioned by him and fully fdinst 
> / fdnpkg compatible :-)

Will do. Hopefully by the end of the day!

> Thank you for your help! Regards, Eric

No problem. Glad to help!___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Jerome Shidel]

Hi,

> On Mar 27, 2020, at 11:03 PM, Mercury Thirteen via Freedos-user 
>  wrote:
> 
> Hi Jerome, Eric!
> 
> 
> On Friday, March 27, 2020 1:16 PM, Jerome Shidel jer...@shidel.net 
>  wrote:
> 
> Hi Eric,
> I took a quick look.
> There is some minor confusion and package issues and they cannot be replace 
> the current packages “AS-IS”.
> At a glance…
> Are they all newer than the ones already in the repo?
> 
> Since the author did not assign explicit version numbers, I had been 
> generating version numbers based on the date of the most recent modification 
> in the change log section of the readme file. However, since some changes 
> were to the documentation only and did not affect the code, this resulted in 
> a newer version number than the existing package despite the included binary 
> being identical. I had listed the "makeshift" versions on my site, but not to 
> the individual LSM files in hopes I could dig up some "real" final version 
> numbers somewhere. These issues have all been fixed in the versions I 
> uploaded today - all versions listed are pulled directly from the binaries 
> themselves, the LSM files have been modified accordingly, and I also updated 
> the descriptions of the packages to further indicate the differences between 
> my packages and any existing ones on the ibiblio list.

That is understandable. 

As a side note…

The repository management utilities require a version (along with things like 
title and some other mandatory fields). The version information must be unique. 
No two packages with the same filename can have the same version. If a version 
3.34 is in the repo, you cannot add the same package as version 3.34. You would 
need to update its ism to something like 3.34b, 3.34-1, 3.34.1 or whatever. 
There is no specified format for version information. This like “5.13.19”, 
“2019-05-13”, “19-May-13 (pre-1, RP ed)” and etc are all fine.

In the ones I looked at, the Entered-date field in your packages looked fine. 
But, I figured I’d mention that it is strict format of -MM-DD. This is 
enforced by the repo management software to provide a uniform look across all 
packages.

Just some more notes on LSM metadata files.

The required Description field should be fairly short and preferably one good 
sentence to describe the package.

There are a couple addition fields the repo knows that are used for various 
things like html pages and RSS feeds. None of them are required.

Summary: A more detailed description of the package. 

Changes: Simple note on what has changed since the last version. 

Modified-date: Formatted as -MM-DD.nn and if not present will be 
automatically stamped with the current date by the repo. Eventually, this may 
be used by software instead of trying to parse version numbers. 
> For example…, RDISK shows no version in package, web page says 2011-04-25. 
> Repo version is 2015-03-05.
> 
> Can one of you point me to the existing RDisk package (and XMgr too, if one 
> exists)? I only found SRDisk on the ibiblio list.
> 

At present… 

There are two main FreeDOS software repos.

The Official FreeDOS software Repository — (html interface) 
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/index.html
 

My unofficial repository — 
http://fd.lod.bz/repos/current/pkg-html/comparison.html 


The Official repo is where all the packages for a FreeDOS release come from. 
Some packages do not exist on it for various reasons. 

My repo is far less strict. As long as it can be legally distributed, I’m 
willing to include it. It contains all the packages and versions that are in 
the Official repo plus more versions and packages that are not present. 
Sometimes, packages are pushed here prior to being approved for inclusion on 
the Official repo.

At present, neither RDISK or XMGR exist on the Official Repo. 

https://fd.lod.bz/repos/current/pkg-html/rdisk.html 

https://fd.lod.bz/repos/current/pkg-html/xmgr.html 


The others are on both repos.

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/himemx.html
 

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/udvd2.html
 

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/uide.html
 


Someday… Programs like FDIMPLES will be capable of fetching packages and 
updates from multiple online 

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Eric Auer]

Hi Mercury, some short answers :-)

I think dates as version numbers are fine when there is
no explicit version numbering. I would use the date of
the most recent file, leave the decision to you whether
that means the version is this week since YOU yourself
have made per-driver excerpts of the readmes. Otherwise,
use the newest timestamp of the original files, even in
situations where only documentation updates took place.

Regarding sources, please always use source\NAME\FILE.EXT
naming. It is no problem to have separate copies of CC in
source\uide\cc.asm and source\uhdd\cc.asm when installed.

There is an official howto for the directory tree etc. in
ZIP files for install friendly packages, somewhere online.

Having two himemx variants to compare sounds like Japheth
hopes to get MANY TESTERS so a new update can consolidate
into one version again? Or maybe a command line option to
pick one of the two styles now represented by two exes?

I suggest that you give Jerome a signal when you think the
packages on your website have been updated to fix all items
mentioned by him and fully fdinst / fdnpkg compatible :-)

Thank you for your help! Regards, Eric




___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Mercury Thirteen via Freedos-user]

Hi Jerome, Eric!

On Friday, March 27, 2020 1:16 PM, Jerome Shidel jer...@shidel.net wrote:

> Hi Eric,
> I took a quick look.
> There is some minor confusion and package issues and they cannot be replace 
> the current packages “AS-IS”.
> At a glance…
> Are they all newer than the ones already in the repo?

Since the author did not assign explicit version numbers, I had been generating 
version numbers based on the date of the most recent modification in the change 
log section of the readme file. However, since some changes were to the 
documentation only and did not affect the code, this resulted in a newer 
version number than the existing package despite the included binary being 
identical. I had listed the "makeshift" versions on my site, but not to the 
individual LSM files in hopes I could dig up some "real" final version numbers 
somewhere. These issues have all been fixed in the versions I uploaded today - 
all versions listed are pulled directly from the binaries themselves, the LSM 
files have been modified accordingly, and I also updated the descriptions of 
the packages to further indicate the differences between my packages and any 
existing ones on the ibiblio list.

> For example…, RDISK shows no version in package, web page says 2011-04-25. 
> Repo version is 2015-03-05.

Can one of you point me to the existing RDisk package (and XMgr too, if one 
exists)? I only found SRDisk on the ibiblio list.

> HIMEMX contains two EXE versions? Why?

According to the readme: "Currently there are 2 versions of HimemX supplied, 
HimemX and HimemX2. HimemX2 uses a different strategy when it comes to extended 
memory block allocations."

> Where is the License file that was in previous versions?

Japheth no longer includes it, instead he added a License section to the readme 
file.

> All packages extract sources to the SOURCE path. This is a problem if the 
> user selects install sources. For example, both UHDD and UIDE contain a 
> SOURCE\CC.ASM file. This will collide and cause package installation to fail 
> with FDNPKG and FDINST.

I see that could be problematic, even if they are the same file. I could 
separate CC into its own package, perhaps. Any thoughts from you guys on 
whether or not that's an appropriate way to handle this issue?

> Some other docs seem to be missing. Like UIDE\UIDE.TXT. (may no longer be 
> needed, IDK)

This file was not included in the driver pack from which I split off the 
individual packages, but the existing readme has its own collection of 
technical notes. From that I conclude it no longer applies to the current 
version.

> Unfortunately, I don’t have the spare time to dedicate to carefully go over, 
> verify and adjust them at present.

No problem, I understand how time-consuming this can be!___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Jerome Shidel]

Hi Eric,


> On Mar 27, 2020, at 7:16 AM, Eric Auer  wrote:
> 
> 
> Hi Jerome,
> 
>> The package UIDE contains UHDD.
>> It was updated to the latest versions almost a year ago.
> 
> Mercury has recently created separate packages for
> all different drivers, with separate readme, source
> and so on. Please use those for 1.3, so people do
> not have to search for UHDD in the UIDE package.

I took a quick look.

There is some minor confusion and package issues and they cannot be replace the 
current packages “AS-IS”. 

At a glance… 

Are they all newer than the ones already in the repo? For example…, 
RDISK shows no version in package, 
web page says 2011-04-25. Repo version is 2015-03-05.

HIMEMX contains two EXE versions? Why? Where is the License file that 
was in previous versions?

All packages extract sources to the SOURCE path. This is a problem if 
the user selects install sources. For example, 
both UHDD and UIDE contain a SOURCE\CC.ASM file. This will collide and 
cause package installation to fail with 
FDNPKG and FDINST. 

Some other docs seem to be missing. Like UIDE\UIDE.TXT. (may no longer 
be needed, IDK)

Unfortunately, I don’t have the spare time to dedicate to carefully go over, 
verify and adjust them at present. 

Jerome

___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Eric Auer]

Hi Jerome,

> The package UIDE contains UHDD.
> It was updated to the latest versions almost a year ago.

Mercury has recently created separate packages for
all different drivers, with separate readme, source
and so on. Please use those for 1.3, so people do
not have to search for UHDD in the UIDE package.

Note that UIDE itself should only be used for tiny
boot floppy purposes as UHDD + UDVD2 together are
more modern than UIDE alone, and fix some bugs.

Thank you Jerome and thank you Mercury! :-)

http://mercurycoding.com/downloads.html#DOS
(UDVD2, UHDD, UIDE, RDISK, XMGR, see also my PS)

Regards, Eric

PS: Mercury also made a HIMEMX 3.35 package with
Japheth's updates. Please check how well it works
on both very new and very old computers. It should
be an improvement over Rob Pemberton's "3.34 RP":

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/himem/himemx/



___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Jerome Shidel]

The package UIDE contains UHDD. It was updated to the latest versions almost a 
year ago.

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/pkg-html/uide.html
 


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Eric Auer]

Hi Rugxulo,

Skipping over the FUD undertone, here are some answers :-)

Yes the UHDD updates in 2019 are useful and by the author.

Yes UHDD + UDVD2 works better than using only UIDE alone.

No this is not about RDISK or XMGR updates, although if you
can be more specific, I can check whether ibiblio needs them.

Yes UHDD and UIDE have different performance features
and UHDD is significantly better in various aspects.

Yes UDVD2 is fine in spite of having no recent updates.

Yes EMM386 can have troubles with new hardware. But:
Yes Japheth is updating his EMM386 JEMM right now.

You ask whether anybody should still use UIDE alone:
Probably no. It is a bit smaller. Maybe floppy users.

Yes the 2019 releases of the drivers are free and open.

Regards, Eric



___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Rugxulo]

Gruess Gott,

On Mon, Mar 9, 2020 at 5:59 AM Eric Auer  wrote:
>
> > As far as I'm concerned, UIDE [sic] died in 2015.
>
> Another reason to switch to UHDD and UDVD2.

I meant that I'm only personally aware of the 2015 "drivers" (long ago
abandoned). I was not directly informed of the later "ad hoc" early
2019 update of one, lonely file (UHDD.SYS). So I don't know the
difference because I only ever ran UIDE.SYS (which apparently is
defective or at least designed differently, according to you).

Who even takes credit for the 2019 update? Certainly it can't be the
original developer, can it? He still maintains his closed source
variant (last updated in November 2019), for zero practical advantage.
Why have so many competing variations (market segmentation??)?

> You do know that the 2019 version *does* include full sources
> of UDVD2, UHDD, UIDE and XMGR, I hope.

AFAIK, the developer is aware of and has elsewhere fixed known bugs in
RDISK and XMGR. But none of those fixes were propagated back to the
2015 version (UIDE, aka not XIDE) for FreeDOS on iBiblio. Why is that?

> Replying to my list, you ask for more exact descriptions of the
> improvements in the currently-on-ibiblio 2019 UHDD and UDVD2:
>
> Better performance: UHDD 10% faster with read-ahead than UIDE.

Were these two designed differently? Or is this only in hindsight,
i.e. some 2019-era bugfix of older 2015 code? Why have two separate
versions that behave differently? (There could be a good reason, I
just don't know why exactly.)

> Because UHDD (and UDVD2, in spite of being "old")

"Old" is fine when it works. I'm not complaining about age but moreso
bugs, regressions, restrictions, licensing, redistribution. Also,
having too many subvariants and releases is confusing. It shouldn't be
so fragmented.

> recognize more drives as DMA/UDMA compatible, without false
>  positives, they give much better performance in those cases
> compared to situations where UIDE fails to detect the DMA support.
> This can mean up to several *times* faster in EMM386 context, as
> a BIOS would rarely bother to call the VDMA API to support
> fast protected mode or VM86 disks on DMA and rather use PIO.

I was under the impression that most EMM386s were unreliable on newer
hardware. So I don't try to use them too much. (Then again, CSM is
basically dead, so who cares.)

Yes, Japheth has updated JEMM386 a few times in recent months. Is that
the one you're referring to, or do you refer to other (much older,
more limited, buggier) vendors? Which ones have been tested in recent
years with these drivers? But even with JEMM we have several versions
(5.78, 5.79, 5.80-pre1) and subvariants (e.g. jemmex or jemm386). I'm
not complaining, we're lucky to have it, it's just a lot for people to
test (but most people don't). So I haven't tried it lately.

> > How is that even possible? Too many versions, too many
> > (alleged) bug fixes! Ridiculous!
>
> Being too annoyed to look at the new version will not make
> the new version worse. That is just your personal opinion.

Is UIDE.SYS completely irrelevant in lieu of UHDD.SYS + UDVD2.SYS?
Seriously, do you know? Is there literally any reason anymore to use
UIDE.SYS? Were they just designed differently, or is this only a
result of UHDD.SYS being "fixed" in early 2019??

> PS: The drivers are deliberately freeware with sources without
> giving a specific license as the author is against fine print.

FreeDOS, by design, has always favored free/libre or "open source".

* http://wiki.freedos.org/wiki/index.php/Open_source_software
* https://sourceforge.net/p/forge/documentation/userfaq/#free
* https://www.gnu.org/philosophy/free-sw.en.html

Going closed source for unjust reasons for zero practical advantage is
user hostile and the exact kind of thing that the GPL was designed to
avoid. No amount of partial updates and pretend lip service can change
that. He made a choice, based upon nothing, despite correction and
proof, but instead still keeps punishing end users, for literally no
gain. What a waste of time.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Eric Auer]

Hi Jim,

> I think this is an oversight in FreeDOS 1.3. I did review UDVD2 and the
> others and said they were ok for FreeDOS 1.3. They are listed as such
> (green) on the Packages page.
> http://wiki.freedos.org/wiki/index.php/Releases/1.3/Packages
> 
> Unless I'm missing something?

I agree: It seems that while UDVD2 is included, there could
be a more explicit mention and inclusion of UHDD and the
fact that UDVD2 combined with UHDD is strongly recommended
over using the integrated but older UIDE driver instead.

So apparently we should simply add UHDD to FreeDOS 1.3 as
UDVD2 already is there :-)

Eric




___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Jim Hall]

I think this is an oversight in FreeDOS 1.3. I did review UDVD2 and the
others and said they were ok for FreeDOS 1.3. They are listed as such
(green) on the Packages page.
http://wiki.freedos.org/wiki/index.php/Releases/1.3/Packages


Unless I'm missing something?

Jim

On Mon, Mar 9, 2020, 5:59 AM Eric Auer  wrote:

>
> Hi Rugxulo, Jerome, Jim et al,
>
> > The full 1.2 release was from late 2016 / early 2017.
> > It hasn't changed.
>
> Good point, although 1.3 is still pending, so people
> might still want to update while they only have 1.2.
>
> > As far as I'm concerned, UIDE [sic] died in 2015.
>
> Another reason to switch to UHDD and UDVD2.
>
> > That makes no sense (to me). UHDD.SYS (from 2015) indeed had a
> > surprise update in early 2019 (dunno what changed, ask Jim), but
> > UDVD2.SYS is still dated 2015.
> >
> > *
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/cdrom/uide/
> >
> > "It would probably be better" ... if XIDE/XHDD/XDVD2 (or whatever he
> > calls it nowadays) wasn't unjustly "closed source" for five years!
>
> You do know that the 2019 version *does* include full sources
> of UDVD2, UHDD, UIDE and XMGR, I hope. And I do *not* remember
> attempts by other programmers to update them which would have
> failed during the period when sources were unpublished, simply
> because low level drivers rarely get updates from new people.
>
> Replying to my list, you ask for more exact descriptions of the
> improvements in the currently-on-ibiblio 2019 UHDD and UDVD2:
>
> Better performance: UHDD 10% faster with read-ahead than UIDE.
>
> 386 compatibility: UHDD can run on 386, while UIDE follows old
> Microsoft advice which causes XMS move errors on older 386 CPU.
>
> Improved drive detection and LBA: UHDD supports DMA on SSD (as
> well as CF) which claim to be "ATA / ATAPI" while UIDE would
> have ignored them as potentially optical, expecting *only* ATA
> to be supported. UIDE supports only old LBA for the first 128
> GB, while UHDD supports LBA48 and larger disks. Note that DOS
> itself has a 2 TB limit until somebody adds GPT partition code.
>
> Because UHDD (and UDVD2, in spite of being "old") recognize
> more drives as DMA/UDMA compatible, without false positives,
> they give much better performance in those cases compared to
> situations where UIDE fails to detect the DMA support. This
> can mean up to several *times* faster in EMM386 context, as
> a BIOS would rarely bother to call the VDMA API to support
> fast protected mode or VM86 disks on DMA and rather use PIO.
>
> > How is that even possible? Too many versions, too many
> > (alleged) bug fixes! Ridiculous!
>
> Being too annoyed to look at the new version will not make
> the new version worse. That is just your personal opinion.
>
> > These decisions (for FD 1.3) rely mostly on Jerome and Jim.
>
> Then I recommend UHDD and UDVD2 to Jerome and Jim, specifically.
>
> Regards, Eric
>
> PS: The drivers are deliberately freeware with sources without
> giving a specific license as the author is against fine print.
>
>
>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2 - and 1.3

[Eric Auer]

Hi Rugxulo, Jerome, Jim et al,

> The full 1.2 release was from late 2016 / early 2017.
> It hasn't changed.

Good point, although 1.3 is still pending, so people
might still want to update while they only have 1.2.

> As far as I'm concerned, UIDE [sic] died in 2015.

Another reason to switch to UHDD and UDVD2.

> That makes no sense (to me). UHDD.SYS (from 2015) indeed had a
> surprise update in early 2019 (dunno what changed, ask Jim), but
> UDVD2.SYS is still dated 2015.
> 
> * https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/cdrom/uide/
> 
> "It would probably be better" ... if XIDE/XHDD/XDVD2 (or whatever he
> calls it nowadays) wasn't unjustly "closed source" for five years!

You do know that the 2019 version *does* include full sources
of UDVD2, UHDD, UIDE and XMGR, I hope. And I do *not* remember
attempts by other programmers to update them which would have
failed during the period when sources were unpublished, simply
because low level drivers rarely get updates from new people.

Replying to my list, you ask for more exact descriptions of the
improvements in the currently-on-ibiblio 2019 UHDD and UDVD2:

Better performance: UHDD 10% faster with read-ahead than UIDE.

386 compatibility: UHDD can run on 386, while UIDE follows old
Microsoft advice which causes XMS move errors on older 386 CPU.

Improved drive detection and LBA: UHDD supports DMA on SSD (as
well as CF) which claim to be "ATA / ATAPI" while UIDE would
have ignored them as potentially optical, expecting *only* ATA
to be supported. UIDE supports only old LBA for the first 128
GB, while UHDD supports LBA48 and larger disks. Note that DOS
itself has a 2 TB limit until somebody adds GPT partition code.

Because UHDD (and UDVD2, in spite of being "old") recognize
more drives as DMA/UDMA compatible, without false positives,
they give much better performance in those cases compared to
situations where UIDE fails to detect the DMA support. This
can mean up to several *times* faster in EMM386 context, as
a BIOS would rarely bother to call the VDMA API to support
fast protected mode or VM86 disks on DMA and rather use PIO.

> How is that even possible? Too many versions, too many
> (alleged) bug fixes! Ridiculous!

Being too annoyed to look at the new version will not make
the new version worse. That is just your personal opinion.

> These decisions (for FD 1.3) rely mostly on Jerome and Jim.

Then I recommend UHDD and UDVD2 to Jerome and Jim, specifically.

Regards, Eric

PS: The drivers are deliberately freeware with sources without
giving a specific license as the author is against fine print.



___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE versus UHDD in freedos 1.2

[Rugxulo]

Gruess Gott,

On Sun, Mar 8, 2020 at 10:12 AM Eric Auer  wrote:
>
> It seems that FreeDOS 1.2 currently includes UIDE.

"Currently"?? The full 1.2 release was from late 2016 / early 2017. It
hasn't changed.

As far as I'm concerned, UIDE [sic] died in 2015.

> It would probably be better to use UHDD and UDVD2 instead:

That makes no sense (to me). UHDD.SYS (from 2015) indeed had a
surprise update in early 2019 (dunno what changed, ask Jim), but
UDVD2.SYS is still dated 2015.

* https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/cdrom/uide/

"It would probably be better" ... if XIDE/XHDD/XDVD2 (or whatever he
calls it nowadays) wasn't unjustly "closed source" for five years!
That would've saved a lot of end users tons of frustration.

Then again, most of them "just use Linux", it works! (I'm on a
Chromebook now. Isn't "Free Software" great?? GPL FTW!)

> Those

Which exactly? Where are they? What versions?

> have better performance

Than who? Which versions exactly?

> and better 80386 style XMS compatibility

XMSv3? (You know that DR-DOS 7.03's XMS faked its version number and
really only supported XMSv2, i.e. 64 MB limit.)

> on old computers

Which? Actually 386 or 486 cpus? Pre-LBA BIOSes?

> , as well as improved drive detection, DMA choices, support for disks above 
> 128 GB size and more good news :-)

How is that even possible? Too many versions, too many (alleged) bug
fixes! Ridiculous!

> Thanks for considering!

These decisions (for FD 1.3) rely mostly on Jerome and Jim.

But discussing these drivers is always a huge waste of time. I'm tired
of hearing about it. It's unproductive, to put it politely.


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE Updates: NOT Losing My Mind!

[Eric Auer]

Jack,

another week, another UIDE update is probably just a compliment, no
complaint... Regarding your most recent update: Until we support EFI
(UEFI?) GPT partitioning, FreeDOS only supports 2^32 sectors for FAT
partitions on int13 disks in the kernel. However, it is possible that
some driver (e.g. for USB media) supports GPT itself and/or supports a
filesystem (not FAT, probably also not ISO9660 nor UDF) for partitions
or unpartitioned media which extend beyond 2^32 sectors.

You could decide to not cache such drives. Or you could decide to
(carefully) cache only the first 2^32 sectors. Or you could support
LBA48 or even 64 bit sector numbers. In my personal opinion, your choice
to support 2^32 sectors is fine as long as no DOS kernel and no popular
driver for DOS supports larger disks. If you need a spare bit for flags,
even caching only the first 1 TB (2^31 * 512 byte) would be ok for me.

Of course you could pool updates - but people can decide themselves if
they personally need a specific update or if they want to wait until a
few other interesting changes become available before they update. In
that sense, release early, release often can work for everybody.

Regards, Eric

PS: I think it is nice to announce updates on multiple channels, e.g.
BTTR forum, freedos.org and this mailing list here.



--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] uide versus virtualbox versus ls120 - was: DISGUSTED With Pundits!!

[Eric Auer]

Hi! (BCCing Jack and Mr. Lego)

If I understand you correctly, you deliberately make
incompatible for many VirtualBox users in order to fix
it for a few users with LS120 drives with broken BIOS
support?

Can you give more details about the way in which the
BIOS of Christian Pfaller fails to report the LS120?
By the way, is it supported as LS120 or just as 1.4M?

 Eric, if your VBOXFIX program is still available, you might
 want to re-issue it, with its specific logic to test the bits
 in the BIOS diskette flag byte for the presence of diskettes,
 when VirtualBox is used.   I intend to use that byte again,

Did anybody with connections to the VirtualBox community
or a bug reporting account report the lack of support
for this semi-undocumented BIOS flag byte to VirtualBox?

By the way, why do you publish that mr-lego.fd web.de
email address to the list? Did Christian ask for that?

 For example I load UIDE with the parameter /S25 (with 25MB-cache).
 If I check now a LS120 diskette with DOSFSCHK, it told me that the first
 and the second FAT are not be the same.
 
 Now I load UIDE with the parameter /B (basic, without cache).
 Then I check the LS120 diskette with DOSFSCHK, no errors were found.

I still wonder how THAT would by influenced by whether or not
UIDE caches the drive? Or does UIDE get the geometry wrong or
some completely different problem arises? Because I assume by
flag byte you mean the byte saying whether the drive exists?

 This problem only appears with the LS120 Diskette Drive.

Regards, Eric



--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] uide versus audio cd versus udvd

[Karen Lewellen]

The ability to rip audio cds has been built into the mpxplay dos audio 
player package for years.  Given  it now includes audio formats from .aif 
to .acc to m4a and mp4  and still allows for audio cd ripping, clearly 
many people care.
Karen

On Sun, 12 Aug 2012, Eric Auer wrote:


 Hi, short question about CD-DA: The UDVD driver saves a tiny
 amount of RAM by not supporting raw sector reads, so if you
 want to rip audio CD to audio files, you have to use UIDE,
 the more complete driver.  My question is: Who does audio CD
 ripping in DOS at all? Depending on that, it might be worth
 enabling raw read in UDVD, making it more known that raw is
 only available in UIDE, or maybe do nothing as nobody cares?

 Regards, Eric :-)

 PS: I myself prefer cdparanoia-related abcde to rip in Linux.


 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE Diskette Change Line Capability Tests.

[Bret Johnson]

Jack:

Are you more interested in actually getting your program to work, or in trying 
to prove that you're smarter than everybody else?

Let's take this from the perspective of someone trying to write a BIOS.  If I 
were trying to do that, I would do my due diligence and obtain as many 
references as I could.  This would include BIOS Central, RBIL, and as many 
hard books as I could reasonably get hold of.  Some people have been doing 
research on this in the background, and nobody yet has reported a hard book 
saying anything at all 40:8F.

BIOS Central says one thing, RBIL says another.  Which one is right?  Maybe 
both (different BIOS's on different computers), maybe neither.  I do know that 
both of these are secondary, not primary, sources.  At least some of their 
information is gathered by experimentation on specific computers, and can be 
pure conjecture.  Extrapolating information from specific computers and 
applying it to all computers is, at best, reckless.

Which one do I believe?  I can't believe either one.  I need another source of 
corroboration, one that I know didn't just copy their information from BIOS 
Central or RBIL.

So, I go to a primary, official source -- The IBM Technical Reference (it 
doesn't get any more official or primary than that).  The IBM PS/2 Technical 
Reference from 1991 simply says that 40:8F is Reserved.

So, what do I do with 40:8F in my BIOS?  The short answer is, I can do anything 
I want.  If somebody points the finger back at me and says, It should work 
like BIOS Central says, I can laugh and say, Says who?  BIOS Central does 
not have any more credibility than RBIL, and neither one of them can touch IBM.

UIDE is using an undocumented and unverifiable feature and needs to be fixed.  
VirtualBox is following the rules.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE Diskette Change Line Capability Tests.

[Jack]

Bret,

A favorite tactic of propagandists, be they Fascist/Nazi/Communist
or others, is that they flatly IGNORE any information from opponents
and simply go on spouting their own ideas.

In responding to the above thread, you have totally IGNORED all info
I offered to begin with, and you cite, as your reference, a 1991 IBM
Technical Reference for the PS/2.

That reference is now 21 years old, and was written for a computer
that AFAIK has NOT been sold by IBM for YEARS!   I can also note how
IBM in fact LOST control of their own PC market beginning about 1985
to vendors in Japan and Asia, due largely to the same class of FIXED
thinking that you now exhibit!   IBM thought they were Gods and Asia
did not matter, and Asia just MASSACRED IBM in their own marketplace
same as Crazy Horse did to Custer in 1876!   I have NEVER given much
trust to IBM, surely not after 1985, and I never will!

So I will say it all again, for the cheap seats --

(A) The 1991 IBM Technical Reference for a PS/2 is 21 years old, was
 written for a system that is now obsolete, and MAY NOT have been
 kept current.

(B) Using byte 0:048Fh is not undocumented.   BIOS Central has noted
 this from at-least 2006, when I first read their BIOS data list.

(C) As of 11-Jan-2007, 16 years PAST your IBM reference, Phoenix and
 maybe other BIOS vendors do in fact support byte 0:048Fh exactly
 as BIOS Central describes that byte.   I have such a BIOS, and I
 expect others using a hardware PC can verify that 0:048Fh DOES
 work exactly as BIOS Central indicates, DESPITE some 21-year-old
 IBM reference calling that byte reserved.

(D) UIDE/UIDE2 have NEVER failed, to my knowledge, to cache diskette
 data and deal with diskette media-changes, if used on any actual
 hardware PC system.   If so, I want to KNOW about it and shall
 FIX any such problems, REAL QUICK!!

(E) VirtualBox handling of diskette change-lines IS IN DOUBT!   Eric
 did find (yesterday) a source file in which THEY DO set the byte
 at 0:048Fh, despite other parts of their emulator saying they do
 NOT support diskette change-lines.   Since Their RIGHT hand may
 not know what their LEFT is doing! (a usual result re: too many
 programmers on one task!), I believe it is WRONG to say they are
 following the rules.   WHOSE rules??   Even THEY seem not able
 to agree among THEMSELVES what those rules ARE!!

And now, Bret, DO NOT merely spout your own propaganda again!   If
you have more to say, speak to the points -- SPEAK TO THE POINTS! --
that I have listed above!!

And do so in private, as after this E-Mail, I will again unsubscribe
 from FD-User.Jack is right and everyone else is an idiot, Are
you trying to prove yourself smarter than everyone else, plus other
such INSULTS will be ENOUGH for me!

Use UIDE/UIDE2 if you think they work.   Otherwise, do not use them.
Your choice.   I think they work, I have evidence to say they should
and NO actual PROOF to the contrary.   So I will leave them as is.

Jack R. Ellis

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE Diskette Change Line Capability Tests.

[Eric Auer]

Jack, Bret, VirtualBox users,

 A favorite tactic of propagandists, be they Fascist/Nazi/Communist
 or others, is that they flatly IGNORE any information from opponents

At this point, you lost the discussion and many readers will
simply have skipped the rest of your mail, as explained here:

http://en.wikipedia.org/wiki/Godwin%27s_law#Corollaries_and_usage



 In responding to the above thread, you have totally IGNORED all info
 I offered to begin with, and you cite, as your reference, a 1991 IBM
 Technical Reference for the PS/2.

No. The point was that BIOS Central, RBIL, Tischer and other
reputable sources disagree* about 40:8f and therefore, even
though each individual source is reputable, 40:8f is not a
safe way to decide about floppy change lines. On the other
hand, all sources do agree about int 13 for that purpose.

* can mean ONE thing, ANOTHER thing, or be a RESERVED byte.

 (C) As of 11-Jan-2007, 16 years PAST your IBM reference, Phoenix and
  maybe other BIOS vendors do in fact support byte 0:048Fh exactly

The weak point is in maybe other here.

 (D) UIDE/UIDE2 have NEVER failed, to my knowledge... on any actual
  hardware PC system.   If so, I want to KNOW about it...

Virtual machines are widespread now, their users deserve support.



 (E) VirtualBox handling of diskette change-lines IS IN DOUBT!

The comment in orgs.asm indeed supports your claim that VirtualBox
is in conflict with itself IF 40:8f really means what UIDE thinks.
However, documentation about that very byte is contradictionary...

Also, DOSEMU treats the same byte as reserved (0) and is backed by
literature for this. As long as you can find support in literature
for multiple interpretations of the same byte, it is not safe to
demand from all BIOSes to interpret the byte in one specific way.

Note that I was not able to download rombios.c from BIOS so all
statements about me reading VirtualBox sources are limited to the
BIOS-new directory and I do not know which version is used when.



 Use UIDE/UIDE2 if you think they work. Otherwise, do not use them.

The third choice is giving my prosthetic helper a try ;-) Users
of VirtualBox and UIDE, but also of other systems including real
hardware, are invited to write me off-list, so I can send a copy
and receive feedback :-) My tool does the following: It installs
a PCI BIOS handler where scans are limited to existing bus numbers
(VirtualBox has 1 bus but VirtualBox BIOS scans 256) which should
speed up UIDE init a lot. This function is an experimental TSR and
takes circa 400 bytes of DOS RAM. Loading into UMB with LH should
be possible without problems. The other function does not take any
DOS RAM: It simply enforces the expected-by-UIDE semantics for the
BIOS Data Area byte 40:8f - This should protect you from data loss
in VirtualBox and should enable UIDE caching of floppies in DOSEMU.

Regards, Eric :-)


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE Diskette Change Line Capability Tests.

[Jim Hall]

 Use UIDE/UIDE2 if you think they work. Otherwise, do not use them.

 The third choice is giving my prosthetic helper a try ;-) Users
 of VirtualBox and UIDE, but also of other systems including real
 hardware, are invited to write me off-list, so I can send a copy
 and receive feedback :-) My tool does the following: It installs
 a PCI BIOS handler where scans are limited to existing bus numbers
 (VirtualBox has 1 bus but VirtualBox BIOS scans 256) which should
 speed up UIDE init a lot. This function is an experimental TSR and
 takes circa 400 bytes of DOS RAM. Loading into UMB with LH should
 be possible without problems. The other function does not take any
 DOS RAM: It simply enforces the expected-by-UIDE semantics for the
 BIOS Data Area byte 40:8f - This should protect you from data loss
 in VirtualBox and should enable UIDE caching of floppies in DOSEMU.


Out of curiosity, why not post the tool online, and share the URL on
this list so people can try it? A key part of free / open source
software is making our programs easily available to everyone so people
can use them.


-jh

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE Performance -- Small Caches DO Work O.K.!

[Santiago Almenara]

Welcome back!

Sent from my iPhone

On 23/08/2011, at 23:50, Jack gykazequ...@earthlink.net wrote:


 For years, I have told people to use as much cache as
 possible with UIDE, to handle today's large files and
 still leave space in the cache for DOS directories.

 Today, Tuesday 23-Aug-2011, I ran experiments using
 a driver equal to UIDE-S, with a new 10-MB cache size
 of 1280 8K-byte data blocks.   I never liked the 5-MB
 cache that some users MUST have (only 640 blocks, not
 enough data!) so I chose to try a 10-MB tiny cache.

 I ran my usual test of copying a 635-MB video drivers
 CD to disk.   With my regular 500-MB UIDE cache, this
 test takes around 124 seconds, plus-or-minus about 2.

 With only the 10-MB cache, the test took 128 seconds,
 merely 4 seconds more!   I checked 25, 50, and 100-MB
 caches as well, and none suffered in speed from being
 small-sized!   Each performed as well, maybe a hair
 better in some cases, as the 10-MB cache!

 So, it seems I may have been All wet! (misinformed)
 re: UIDE's cache performance v.s. cache size.   Users
 may want to check this on their systems, maybe across
 a variety of applications.   And I expect there are a
 few large file systems which do need larger caches.

 But, it now seems that casual users of DOS and UIDE
 need NOT worry re: using only a 25/50/100-MB cache --
 They do seem to perform a LOT better than I expected!

 Jack R. Ellis


 --
 EMC VNX: the world's simplest storage, starting under $10K
 The only unified storage solution that offers unified management
 Up to 160% more powerful than alternatives and 25% more efficient.
 Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user

--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE Performance -- Small Caches DO Work O.K.!

[JPT]

Hi,

I cannot resist... in the following read my comments on caching and
buffering.

Even Windows XP (did not try nore recent versions yet) suffers from bad
buffering when copying files from and to the same harddrive. It takes
10x to 100x time compared to copying from one drive to another one.
I installed SuperCopier 2.2 beta which catches Explorer copy actions and
does them itself. Well, now you are able to define huge buffers... but
it does not help much, because its a question of filling and flushing
the buffer, as XCOPY did.
!!! beware, supercopy has got a bug when using buffers larger than 64k,
causing it to abort the operation on files larger than 4 gig. !!!
Caching does not help much with operations like this. Ok, caching FAT
and directories...

When working with large files, you always have to code buffering on your
own. For example, I compiled mplex (mpeg muxer) myself using cygwin.
Works correctly but uses the wrong file mode. Result is my RAM gets
filled with cached data from the target file. Everything else gets paged
out. The system breaks down to almost unusable until the process is
finished. Then it takes decades to swap in the other programs again...
What I want to say is, you can have Terabytes of RAM, it won't help in a
case like this when the file operation is about as large as your RAM. If
there was an upper limit for the amount of cache used for a single file,
there would be no problem at all. So small caches sometimes perform even
better!

So guys go tell M$ how to write an operating system!


JPT


--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE /E For VirtualBox Now Officially Released.

[Santiago Almenara]

Jack,

Is there any specific order for UIDE options?

I am using the lastest UIDE (07-22-2011) wtih this options:

C:\DEVLOAD\DEVLOAD /H C:\UIDE\UIDE.SYS /E /H /S:15 /D:MYCDROM

Under VirtualBox, I am having the same problems when detecting the hard disk
than the previous UIDE version.

Thanks,

Santiago

On Sun, Jul 24, 2011 at 5:57 PM, Jim Hall jh...@freedos.org wrote:

 THANKS, Jack!

 I've mirrored this release on ibiblio, and updated the software list.
 A news item should appear on the www.freedos.org site in about an
 hour.



 On Sun, Jul 24, 2011 at 3:15 PM, Jack gykazequ...@earthlink.net wrote:
 
  As noted earlier by Rugxulo, Johnson Lam has now posted
  the 22-Jul-2011 DRIVERS.ZIP file on his website at:
 
  http://johnson.tmfc.net/dos/driver.html
 
  Thus, the new UIDE and UIDE-S, with their /E emulator
  switch for use by VirtualBox, are officially released
  and users need not E-Mail me directly for the files.
 
  Users who had been running UIDE /N1 (no hard-disks), to
  avoid VirtualBox problems, can now try UIDE /E instead.
  /N1 causes UIDE to totally ignore all hard-disks, while
  /E does permit hard-disk data to get cached, after UIDE
  calls the BIOS to do disk I-O.   This is much better!
 
  Jack R. Ellis
 
 
 
 --
  Magic Quadrant for Content-Aware Data Loss Prevention
  Research study explores the data loss prevention market. Includes
 in-depth
  analysis on the changes within the DLP market, and the criteria used to
  evaluate the strengths and weaknesses of these DLP solutions.
  http://www.accelacomm.com/jaw/sfnl/114/51385063/
  ___
  Freedos-user mailing list
  Freedos-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/freedos-user
 


 --
 Magic Quadrant for Content-Aware Data Loss Prevention
 Research study explores the data loss prevention market. Includes in-depth
 analysis on the changes within the DLP market, and the criteria used to
 evaluate the strengths and weaknesses of these DLP solutions.
 http://www.accelacomm.com/jaw/sfnl/114/51385063/
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE /E For VirtualBox Now Officially Released.

[Rugxulo]

Hi,

On Thu, Jul 28, 2011 at 12:01 PM, Santiago Almenara almen...@gmail.com wrote:

 Is there any specific order for UIDE options?

 I am using the lastest UIDE (07-22-2011) wtih this options:
 C:\DEVLOAD\DEVLOAD /H C:\UIDE\UIDE.SYS /E /H /S:15 /D:MYCDROM
 Under VirtualBox, I am having the same problems when detecting the hard disk
 than the previous UIDE version.

Blind guess, but /S15 shouldn't have a colon in it, I think.

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE /E For VirtualBox Now Officially Released.

[Bernd Blaauw]

Op 28-7-2011 23:22, Rugxulo schreef:

 I am using the lastest UIDE (07-22-2011) wtih this options:
 C:\DEVLOAD\DEVLOAD /H C:\UIDE\UIDE.SYS /E /H /S:15 /D:MYCDROM
 Under VirtualBox, I am having the same problems when detecting the hard disk
 than the previous UIDE version.

 Blind guess, but /S15 shouldn't have a colon in it, I think.

And otherwise there's still the options to enable newer hardware 
(IO-APIC, ICH9 chipset instead of 430FX). Pity if the /E setting doesn't 
suffice, but Jack so far did what he can. It's nearly impossible to be 
compatible with everything related to PCI and BIOS. And just to add some 
fun from the EFI (bios replacement) corner:
http://mjg59.dreamwidth.org/



--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE /E For VirtualBox Now Officially Released.

[Jim Hall]

THANKS, Jack!

I've mirrored this release on ibiblio, and updated the software list.
A news item should appear on the www.freedos.org site in about an
hour.



On Sun, Jul 24, 2011 at 3:15 PM, Jack gykazequ...@earthlink.net wrote:

 As noted earlier by Rugxulo, Johnson Lam has now posted
 the 22-Jul-2011 DRIVERS.ZIP file on his website at:

 http://johnson.tmfc.net/dos/driver.html

 Thus, the new UIDE and UIDE-S, with their /E emulator
 switch for use by VirtualBox, are officially released
 and users need not E-Mail me directly for the files.

 Users who had been running UIDE /N1 (no hard-disks), to
 avoid VirtualBox problems, can now try UIDE /E instead.
 /N1 causes UIDE to totally ignore all hard-disks, while
 /E does permit hard-disk data to get cached, after UIDE
 calls the BIOS to do disk I-O.   This is much better!

 Jack R. Ellis


 --
 Magic Quadrant for Content-Aware Data Loss Prevention
 Research study explores the data loss prevention market. Includes in-depth
 analysis on the changes within the DLP market, and the criteria used to
 evaluate the strengths and weaknesses of these DLP solutions.
 http://www.accelacomm.com/jaw/sfnl/114/51385063/
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user


--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE vs drive power management spin down timers

[Jack]

Eric,

I read through and understood all your comments about hard-disk
power management, etc.

My problem is:  I am not-interested in being the one who does
power management.   If DOS or the BIOS wants to save power thru
putting disks into stand-by mode, let them do it.   UIDE is a
disk I-O driver, not a power-management tool, and I desire to
keep such things OUT of UIDE's logic!

Re: handling disk drives which ARE in stand-by mode, if all I
need to do is allow some more time for them to spin-up, that is
relatively easy.   UIDE's CD/DVD logic currently allows 7 secs.
for spin-up and 3 seconds for track-to-track seeks, which I had
forgotten -- I had not looked at that logic for almost 5 years!

Assuming 7 seconds should be long enough! for a hard disk, as
well, I can simply use that value as a timeout during disk I-O,
not the current 400-msec timeout.   Shall experiment re: this
idea.   Might cause some confusion among UIDE users, who will
now see a 7-second delay in some error handling.   But, if UIDE
needs only a timeout change to handle sleeping hard disks, it
might be worth updating only 1 byte in its DoIO subroutine!

Jack R. Ellis


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE vs drive power management spin down timers

[Eric Auer]

Jack,

 I read through and understood all your comments about hard-disk
 power management, etc.
 
 My problem is:  I am not-interested in being the one who does
 power management.   If DOS or the BIOS wants to save power thru
 putting disks into stand-by mode, let them do it...

There is not much to do there, as you only tell the disk once
and then the disk itself does the rest. But it would be good to
know from you that UIDE is (as predicted) happy to wait a moment
for idle disks to spin back up as that in fact does not need any
explicit handling by UIDE anyway.

However, I would be happy if UIDE could do the sending of the
idle timer config command to the disk because: It already does
raw drive I/O anyway and it already has some command line parser
anyway so it would only take a few more (non-resident) bytes to
let UIDE send this command when the user puts the corresponding
command line option during UIDE start-up. That way, no separate
tool would be needed which would duplicate existing UIDE logics.



 UIDE is a disk I-O driver, not a power-management tool, and
 I desire to keep such things OUT of UIDE's logic!

Yet UIDE already probably does drive setup communication with
the disk for selection of the right communication speed so my
point is it would be only a small step to make it possible to
send other drive (e.g. idle timer) setup commands with it.

 relatively easy.   UIDE's CD/DVD logic currently allows 7 secs.
 for spin-up and 3 seconds for track-to-track seeks, which I had
 forgotten -- I had not looked at that logic for almost 5 years!

Interesting. So it can in fact report a time-out, but that should
simply make DOS try again. As FreeDOS tries 5 times, you get much
more than 3 or 7 seconds in the end, depending on which timeouts
are used for int 13 functions 0, 2, 3, 42 and 43. Long enough :-)

 Assuming 7 seconds should be long enough! for a hard disk, as
 well, I can simply use that value as a timeout during disk I-O,
 not the current 400-msec timeout.   Shall experiment re: this

Thanks - and see above.



 idea.   Might cause some confusion among UIDE users, who will
 now see a 7-second delay in some error handling.

Good question. This would only make delays longer for errors that
would never end without explicit error handling but I understand
that users could still notice. For example I remember that using
CompactFlash CF cards with a (purely mechanical) IDE adapter plug
can have such hangs for low quality cards - in particular when
you combine that plug with a SATA-IDE adapter with cheap chipset.

So I guess such hangs would get longer with longer timeouts, as
it might take the driver longer to give up the access attempt
and decide to give the drive a smack of reset to reactivate it
no matter whether it is the driver or just DOS which says reset.

 But, if UIDE
 needs only a timeout change to handle sleeping hard disks, it
 might be worth updating only 1 byte in its DoIO subroutine!

Nice, thanks :-)

Eric

PS: Of course a stall/crash of a CF/SD/... card affects any OS.



--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE vs drive power management spin down timers

[Jack]

Eric,

 ... My problem is:  I am not-interested in being the one who
 does power management.   If DOS or the BIOS wants to save power
 thru putting disks into stand-by mode, let them do it...

 There is not much to do there, as you only tell the disk once
 and then the disk itself does the rest.

Amen!, so let the user handle this thru the BIOS setup routines
and let the BIOS tell the disk what to do during system boot!
BIOS vendors have many more programmers than just me by myself!

 But it would be good to know from you that UIDE is (as predicted)
 happy to wait a moment for idle disks to spin back up, as that in
 fact does not need any explicit handling by UIDE anyway.

UIDE's CD/DVD logic is happy to wait for up to 7 seconds, and I
will look into changing its disk logic from 400-msec to 7 seconds
as well.

 However, I would be happy if UIDE could do the sending of the
 idle timer config command to the disk because:  It already does
 raw drive I/O anyway and it already has some command line parser
 anyway so it would only take a few more (non-resident) bytes to
 let UIDE send this command when the user puts the corresponding
 command line option during UIDE start-up. That way, no separate
 tool would be needed which would duplicate existing UIDE logic.

Actually, UIDE has NOT changed any disk-configuration settings by
the BIOS since late 2005, when I got into TROUBLE doing so with
some BIOS programs!   UIDE now only reads I-O and DMA addresses
for a disk from the BIOS, then runs a disk however the BIOS set
it up.   That, also, is something I want to LEAVE up to the BIOS,
as I don't want any MORE trouble by changing BIOS settings again!

 UIDE is a disk I-O driver, not a power-management tool, and
 I desire to keep such things OUT of UIDE's logic!

 Yet UIDE already probably does drive setup communication with
 the disk for selection of the right communication speed so my
 point is it would be only a small step to make it possible to
 send other drive (e.g. idle timer) setup commands with it.

No, sir!   UIDE does NOT change any communication-speeds nor ANY
other BIOS settings for disks, not since 2005, as I noted above!

 relatively easy.   UIDE's CD/DVD logic currently allows 7 secs.
 for spin-up and 3 seconds for track-to-track seeks, which I had
 forgotten -- I had not looked at that logic for almost 5 years!

 Interesting. So it can in fact report a time-out, but that should
 simply make DOS try again. As FreeDOS tries 5 times, you get much
 more than 3 or 7 seconds in the end, depending on which timeouts
 are used for int 13 functions 0, 2, 3, 42 and 43. Long enough :-)

Any hard-disk function but 2/3/42/43 (reads and writes) is passed
to the BIOS, so function 0 would not be so timed-out by UIDE.   Nor
would UIDE ever declare a timeout -- CD/DVD errors currently post
only general error in such cases, and hard-disk errors would post
only whatever hardware error applies to that part of DoIO which
noted the timeout, likely a DMA error for most cases.   Not a big
problem.   Disk/CD/DVD errors are few and far between, and people
already know that a lot of DOS programs will only display Error!,
leaving exactly WHAT error it was for diagnostic programs, etc.!

 ... Might cause some confusion among UIDE users, who will
 now see a 7-second delay in some error handling.

 Good question.   This would only make delays longer for errors that
 would never end without explicit error handling but I understand
 that users could still notice. For example I remember that using
 CompactFlash CF cards with a (purely mechanical) IDE adapter plug
 can have such hangs for low quality cards - in particular when
 you combine that plug with a SATA-IDE adapter with cheap chipset.

 So I guess such hangs would get longer with longer timeouts, as
 it might take the driver longer to give up the access attempt
 and decide to give the drive a smack of reset to reactivate it
 no matter whether it is the driver or just DOS which says reset.

If DOS does 5 retries, as you indicate, this would cost the user a
maximum of 35 seconds (my 7 seconds * 5 tries) and thus is NOT any
sort of an indefinite hang!I would indicate in UIDE's README
that an actual [rare!] disk error may now take that long, before
DOS gives-up on it and reports something to the user.

 But, if UIDE needs only a timeout change to handle sleeping
 hard disks, it might be worth updating only 1 byte in its DoIO
 subroutine!

 Nice, thanks :-)

That was only my Thought while eating breakfast! this morning,
but I shall test it out, later today!

Jack R. Ellis


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user 

Re: [Freedos-user] UIDE vs drive power management spin down timers

[Eric Auer]

Jack,

 There is not much to do there, as you only tell the disk once
 and then the disk itself does the rest.
 
 Amen!, so let the user handle this thru the BIOS setup routines
 and let the BIOS tell the disk what to do during system boot!
 BIOS vendors have many more programmers than just me by myself!

I have not yet seen a desktop BIOS which implements this, alas. I do
have an adware DOS tool for it, showing a splash screen for a BBS or
similar when you run it and of course bigger than needed, but free.

 Actually, UIDE has NOT changed any disk-configuration settings by
 the BIOS since late 2005, when I got into TROUBLE doing so with
 some BIOS programs!   UIDE now only reads I-O and DMA addresses

Interesting, but which trouble did which setting cause?

 Any hard-disk function but 2/3/42/43 (reads and writes) is passed
 to the BIOS, so function 0 would not be so timed-out by UIDE.   Nor
 would UIDE ever declare a timeout

Why not? There is an error code (0x80) defined for that in int 0x13.

 If DOS does 5 retries, as you indicate, this would cost the user a
 maximum of 35 seconds (my 7 seconds * 5 tries) and thus is NOT any
 sort of an indefinite hang!

What I meant is that when the disk is in a state where only a reset
can make it continue, the driver will wait 7 seconds. If it is in a
state where nothing will make it continue (e.g. un-hotplugged it?),
DOS will take 35 seconds until it displays an error message. In the
7 second case, the user will in the worst case see a delay of 7 sec
plus the time needed to spin up, but more likely only the always-
present delay caused by the time needed to spin up.

 That was only my Thought while eating breakfast! this morning,
 but I shall test it out, later today!

Have a nice afternoon then :-)

Eric


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE vs drive power management spin down timers

[Jack]

Eric,

 I have not yet seen a desktop BIOS which implements this, alas [disk
 spin-down timeouts, etc.].  I do have an adware DOS tool for it,
 showing a splash screen for a BBS or similar when you run it and of
 course bigger than needed, but free.

Desktop BIOS routines are usually not-interested in saving power thru
spin-down timeouts or other such tricks.   Laptop BIOS routines ARE
interested, since their power is limited when using batteries.   Thus
it is mainly laptops we address here, and their BIOS routines DO have
the needed hard-disk logic.

 Actually, UIDE has NOT changed any disk-configuration settings by
 the BIOS since late 2005, when I got into TROUBLE doing so with
 some BIOS programs!   UIDE now only reads I-O and DMA addresses

 Interesting, but which trouble did which setting cause?

With a few BIOS routines back in 2005 (maybe obsolete, now), setting
any UltraDMA mode OTHER than what the BIOS set did not work!   To be
safe, I got RID of such mode-set logic in my drivers, back then.

 Any hard-disk function but 2/3/42/43 (reads and writes) is passed
 to the BIOS, so function 0 would not be so timed-out by UIDE.   Nor
 would UIDE ever declare a timeout ...

 Why not? There is an error code (0x80) defined for that in int 0x13.

Note in my drivers' UltraDMA DoIO subroutine, it is always waiting
for either controller/drive ready or DMA end.   If those events do
not occur, hard to tell if the controller/disk has failed or if they
just took too long.I have assumed a disk will finish I-O in at
most 400 msec, and if not, it was a hardware failure, not a timeout.
So, I have never used BIOS code 080h.   Same situation even if the
DoIO timeout becomes 7 seconds, to handle disk spin-up.   No way I
can know if the hardware failed, so I doubt I can use code 080h.

 If DOS does 5 retries, as you indicate, this would cost the user a
 maximum of 35 seconds (my 7 seconds * 5 tries) and thus is NOT any
 sort of an indefinite hang!

 What I meant is that when the disk is in a state where only a reset
 can make it continue, the driver will wait 7 seconds. If it is in a
 state where nothing will make it continue (e.g. un-hotplugged it?),
 DOS will take 35 seconds until it displays an error message. In the
 7 second case, the user will in the worst case see a delay of 7 sec
 plus the time needed to spin up, but more likely only the always-
 present delay caused by the time needed to spin up.

Understood, if in fact DOS issues a drive-reset on any error.   Also,
note that my drivers do NOT allow removable or hot-pluggable HARD
disks, since I cannot be sure all DOS kernels can handle media-change
events in their HARD-disk logic!

Jack R. Ellis


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE

[Eric Auer]

Hi Marcos, Jack,

 Readme.Txt says Power-saving features such as a 'drive
 spin-down timeout' should be DISABLED.
...
 Is that what I should disable? If so, does this mean that
 the hard disk must keep running all the time if UIDE is used?

Of course DOS will freeze for a short moment when it has to
wait for a harddisk to spin up again, but as I never had a
bigger problem than that with power-saving in DOS without
UIDE, I would like to suggest the opposite of what the UIDE
readme.txt seems to say at the moment:



Could UIDE be used to configure the power saving timeout of
your harddisks? The involved IDE/ATA commands are relatively
simple. They could be sent to either all disks which, based
on their self-ID, support power saving, or to one selected
disk, using any suitable command line syntax for the latter.

Of course UIDE should in addition be able to wait in a safe
way when it encounters a sleeping disk which has to spin up
first. Should be possible with small error handling changes.



This is not to be confused with e.g. bus tri-state or with
power-up in standby or similar extreme power savings. It
is also possible to either standby or suspend disks. I think
the best combination of comfort and savings is STANDBY mode,
as SUSPEND (sleep, communication shut down) would require a
drive reset to wake up which would need extra error handling
and automatic reset / retry etc, in short would be annoying.



Standby simply means the drive spins down so the next attempt
to access it will take a while because the drive will have to
spin up again first. Harddisks have a built-in timer for this
and only need a setup command once to enable auto-sleep. The
setup uses one byte to specify the timeout in a slightly weird
way: 0 = none, 1..240 = N*5 seconds, 241..251 = (N-240)*30 min
which means 5 sec to 20 min or 0.5 to 5.5 hours timeout :-)

Setting the spin-down timeout at the moment when UIDE is loaded
would be a nice combination to would avoid needing other tools.

Regards, Eric



PS: Bus tri-state is at most useful for non-hot unplugging and
needs a heavy reset to re-start the drive, while powering up in
standby is for people who want to reduce boot-up power peaks
by keeping non-boot(!) disks in standby until they are actually
needed. Setting this for a boot disk would be very strange: It
would not save energy and a BIOS timeout might skip the disk.


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE

[Jack]

Eric,

 Of course DOS will freeze for a short moment when it has to
 wait for a harddisk to spin up again, but as I never had a
 bigger problem than that with power-saving in DOS without
 UIDE, I would like to suggest the opposite of what the UIDE
 readme.txt seems to say at the moment:

 Could UIDE be used to configure the power saving timeout of
 your harddisks? The involved IDE/ATA commands are relatively
 simple.   They could be sent to either all disks which, based
 on their self-ID, support power saving, or to one selected
 disk, using any suitable command line syntax for the latter.

 Of course UIDE should in addition be able to wait in a safe
 way when it encounters a sleeping disk which has to spin up
 first.   Should be possible with small error handling
 changes ...

The problem is WHERE does UIDE or any other driver wait for
a sleeping, i.e. stand-by hard disk to awaken again??   The
ATA specs do not make this clear.   Can UIDE simply issue a
drive-select command to the disk and await ready for it?
Or, does UIDE actually have to issue a seek or read, and
then retry that command when first it fails??

If you can determine a reliable way for ALL disks to come out
of stand-by mode, i.e. at what point UIDE should have a long
time-out value, I can program that.   But, it must be COMMON
to all drives, NO exceptions, or it might cause just as much
TROUBLE as it resolves!

Jack R. Ellis


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE driver help

[Bernd Blaauw]

Op 12-5-2011 16:13, James Collins schreef:
 I want to be able to use my cd/dvd drive on my MacBook pro laptop. I have the 
 drivers for UIDE. I have read the readme file, but it is very technical. I 
 could use some help loading the drivers.

 Do I have to edit my config.sys file? Do I put the drivers, that I downloaded 
 on my c drive?

 I could use some help, my goal is to be able to access my cd/dvd drive on my 
 mac while in freedos. Like I could put in a cd and then in freedos change to 
 drive a or b or whatever letter is assigned the cd drive and access a cd in 
 my MacBook pro cd drive.

Loading support for optical disc drives (CD/DVD/BD) by itself is quite 
simple really:
* add a line in CONFIG.SYS (or FDCONFIG.SYS, whichever you're using) as 
follows: DEVICE=C:\FDOS\UIDE.SYS /D:FDCD0001
* add a line in AUTOEXEC.BAT as follows: C:\FDOS\SHSUCDX /D:FDCD0001

Where exactly you add each line to each file is your own decision, 
doesn't matter much. Make sure the FDCD0001 or whichever name you 
choose, is equal for both UIDE and SHSUCDX
However as UIDE is also able to cache/buffer drives, it expects some XMS 
memory provided by for example HIMEM.EXE. In effect:
DEVICE=C:\FDOS\HIMEM.EXE
DEVICE=C:\FDOS\UIDE.SYS /D:FDCD0001

However it might also be possible to disable the cache entirely, and 
thus let UIDE work as a basic (CD) driver without requiring XMS memory 
or XMS driver:
DEVICE=C:\FDOS\UIDE.SYS /D:FDCD0001 /N1 /N3 /B

Above things should work fine, if not let the mailing list know. Both 
UIDE and SHSUCDX have many options and a lot of documentation if you'd 
like to know more.
Ofcourse if your CD drive isn't presented in Virtualbox as being on an 
SATA/IDE controller/port, UIDE won't be much help.

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE Question.

[Robert Riebisch]

japhethx gmail wrote:

 In my previous UIDE comments the word P-R-E-S-E-N-T
 was truncated by whatever forum software is in use to
 the word S-E-N-T!!
 
 No problem here. There are 3 occurances of sent in your first post, and all 
 threee have a nice pre prefix.

Same here in Thunderbird 2.0.0.23 (Windows/20090812) and at
http://www.mail-archive.com/freedos-user@lists.sourceforge.net/msg09851.html.

BUT
https://sourceforge.net/mailarchive/forum.php?thread_name=op.u8y689w0sxzqeq%40dialup-4.246.135.135.dial1.sanjose1.level3.netforum_name=freedos-user
shows only sent three times! Japheth's reply at
https://sourceforge.net/mailarchive/forum.php?thread_name=4B8E1358.3090606%40googlemail.comforum_name=freedos-user
also misses P-R-E (w/o the hyphens).

Must be a SF.net display error.

Threaded view is also defunct.

Robert Riebisch
-- 
BTTR Software
http://www.bttr-software.de/

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE Question.

[Jack]

In my previous UIDE comments the word P-R-E-S-E-N-T
was truncated by whatever forum software is in use to
the word S-E-N-T!!   I have NEVER seen such a thing
occur in E-Mail or forums before!   Please understand
that what seems to be S-E-N-T should be read as the
words At p-r-e-s-e-n-t.   Someone please FIX this!!

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE Question.

[Geraldo Netto]

Hi!

eheheh :)
relax Jack, nice shot regarding uide :)
once english is my second language,
my english is definitely far worse than your :)

Kind Regards and Best Wishes,

Geraldo
Non dvcor, dvco = Sapere Aude
São Paulo, Brasil, -3gmt
site: http://exdev.sf.net/
github: http://github.com/geraldonetto
msn: geraldo_b...@hotmail.com
skype: geraldo-netto
icq: 145-061-456



On 3 March 2010 02:32, Jack mezukoyl...@sprynet.com wrote:
 In my previous UIDE comments the word P-R-E-S-E-N-T
 was truncated by whatever forum software is in use to
 the word S-E-N-T!!   I have NEVER seen such a thing
 occur in E-Mail or forums before!   Please understand
 that what seems to be S-E-N-T should be read as the
 words At p-r-e-s-e-n-t.   Someone please FIX this!!

 --
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE Question.

[japhethx gmail]

 In my previous UIDE comments the word P-R-E-S-E-N-T
 was truncated by whatever forum software is in use to
 the word S-E-N-T!!

No problem here. There are 3 occurances of sent in your first post, and all 
threee have a nice pre prefix.

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE question

[Geraldo Netto]

Hi!

I didn't know that, oops
btw, what is up with FD 1.1?
i still busy(oops, my thesis got rejected here)
but of course, as soon as i can, i'll contribute

See Ya!

Geraldo
Non dvcor, dvco = Sapere Aude
São Paulo, Brasil, -3gmt
site: http://exdev.sf.net/
github: http://github.com/geraldonetto
msn: geraldo_b...@hotmail.com
skype: geraldo-netto
icq: 145-061-456

On 26 February 2010 18:53, Bernd Blaauw bbla...@home.nl wrote:
 Op 26-2-2010 22:17, Geraldo Netto schreef:
 Hi maybeway36,

 Uide is different from lbacache/cdrcache
 Uide enables ultra dma[1] modes for harddisks
 while lbacache/cdrcache do cache for harddisks/cdrom

 Geraldo, by default UIDE includes caching for diskettes, harddisks on
 controllers and IDE/SATA optical devices.
 What UIDE doesn't help with is when using different drivers like USB or
 SCSI CD drivers, or ELTORITO.SYS (for non-emulation booting).

 I think LBACACHE and CDRCACHE have better statistics you can query, though.

 Bernd

 --
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE question

[Geraldo Netto]

Hi maybeway36,

Uide is different from lbacache/cdrcache
Uide enables ultra dma[1] modes for harddisks
while lbacache/cdrcache do cache for harddisks/cdrom

[1] http://en.wikipedia.org/wiki/Parallel_ATA

See Ya,

Geraldo
Non dvcor, dvco = Sapere Aude
São Paulo, Brasil, -3gmt
site: http://exdev.sf.net/
github: http://github.com/geraldonetto
msn: geraldo_b...@hotmail.com
skype: geraldo-netto
icq: 145-061-456

On 26 February 2010 17:41, maybeway36 maybewa...@gmail.com wrote:
 With UIDE (http://johnson.tmfc.net/dos/driver.html), do I need LBACACHE and
 CDRCACHE anymore, or does UIDE server their functions as well?
 -maybeway36

 --
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 Freedos-user mailing list
 Freedos-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freedos-user



--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE question

[Bernd Blaauw]

Op 26-2-2010 22:17, Geraldo Netto schreef:
 Hi maybeway36,

 Uide is different from lbacache/cdrcache
 Uide enables ultra dma[1] modes for harddisks
 while lbacache/cdrcache do cache for harddisks/cdrom

Geraldo, by default UIDE includes caching for diskettes, harddisks on 
controllers and IDE/SATA optical devices.
What UIDE doesn't help with is when using different drivers like USB or 
SCSI CD drivers, or ELTORITO.SYS (for non-emulation booting).

I think LBACACHE and CDRCACHE have better statistics you can query, though.

Bernd

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user