DOS ain't dead

FreeDOS 1.1 is released!

We'd like to announce the release of the FreeDOS 1.1 distribution! Bernd Blaauw has been hard at work, updating our FreeDOS distribution to include the latest packages. Bernd writes: "In its current form this new distribution is best suited as a CD-ROM disk to install FreeDOS from onto harddisk. Sources are included. It might be considered as replacement for the current 'base-only' 1.0 distributions as created by Blair and Jeremy, however it's less functional as it's missing the Live Environment part (\FDOS directory on CD)." Get it at http://www.freedos.org/freedos/files/ - or more directly, from http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/ (Mirror sites should be available in a few days.)

For those who prefer the more complete software set from 1.0, the FreeDOS 1.0 distribution is still available at http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/

Bernd adds:

"Future plans should consist of extending the amount of available programs to the level that 1.0 had, possibly exceeding it. Also not all batchfile work is done yet to guarantee 100% proper working configurations (partitioned harddisk versus unpartitioned versus no harddisk, USB flash drives or not, memdisk or not, various amounts of system memory from 1MB to 4096MB+ etc..)."

2012-01-01 16:05:07 PST by jhall1

> FreeDOS 1.1 is released!

Nobody noticed ... nobody announced: http://sourceforge.net/projects/freedos/files/Kernel/2041/

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Thx for notification. Let's see what's new:

2012 Feb 07 - Build 2041
-------- Jeremy Davis

+ Changes Jeremy
* r1637 fix out of range byte in country.asm
* r1685 add int 2f subfunc 122B and 122D from Eduardo Casino
* r1697 from Pete Batard, do not display CHS mismatch warning
during booting when forcing LBA mode option set
* r1702 improve handling for sectors not 512 bytes in size
(up to 2048 bytes, larger sizes not yet working)
* r1705 add cpu detection so memdisk args supported in 8086 build

Seems like minor changes except the support for 2048 sectors? Where is it used? I know that CDROM use 2kB sectores but it was handled by driver for a long time. I also read that some new HDDs have 4kB sectors but AFAIK they still emulate 512B sectors for system.

---
DOS gives me freedom to unlimited HW access.

> Thx for notification. Let's see what's new:
>
> 2012 Feb 07 - Build 2041
> -------- Jeremy Davis

I think Jeremy had originally planned this for mid-year release last year in 2011 but got sidetracked.

But yeah, it's (vaguely) weird that nobody at FreeDOS mentioned it. This is the first I'm hearing of it being actually released, heh.

> + Changes Jeremy
> * r1637 fix out of range byte in country.asm
> * r1685 add int 2f subfunc 122B and 122D from Eduardo Casino

Accidentally? omitted from previous versions, needed for CHCP.

> * r1697 from Pete Batard, do not display CHS mismatch warning
> during booting when forcing LBA mode option set

Rufus "DOS-on-USB-installer" dude, basically shutting up some scary warnings.

> * r1702 improve handling for sectors not 512 bytes in size
> (up to 2048 bytes, larger sizes not yet working)

Partial hack to hopefully begin work for 4k sector HDs ("teh futurez").

> * r1705 add cpu detection so memdisk args supported in 8086 build

Probably suggested by Bernd as he heavily uses things like that.

> Seems like minor changes except the support for 2048 sectors? Where is it
> used? I know that CDROM use 2kB sectores but it was handled by driver for a
> long time. I also read that some new HDDs have 4kB sectors but AFAIK they
> still emulate 512B sectors for system.

You must've missed the long discussion on the FD mailing lists. One guy ("Czerno"? aka "Grandpied"?) wanted to test on his 4 kb sector USB hard drive or whatever and was hacking the Panasonic USB driver, MS-DOS, etc. So Jeremy whipped up a partial hack (after having barely tested with TDSK) for him. That's all I recall. Search the online archives for more info.

Basically, according to the dude, he says the hard drive industry will basically phase out 512-byte sectors after 2015 (?) or such for various political and technical reasons. So he's saying it may be wise to plan for the future. (Though I think we've got bigger problems with UEFI, but anyways ....)

> You must've missed the long discussion on the FD mailing lists. One guy

Yes, I'm not able to read everything everywhere. I'm not familiar with DOS internals so it was going out of my scope...

> ("Czerno"? aka "Grandpied"?) wanted to test on his 4 kb sector USB hard

Czerno, hmm, I know this name, I remember that I was mailing with him or his brother? but can't remember about what, probably some low level prog...

> Basically, according to the dude, he says the hard drive industry will
> basically phase out 512-byte sectors after 2015 (?) or such for various
> political and technical reasons. So he's saying it may be wise to plan for

That's a bad new. I think that a lot of older programs till now have hardcoded sector size to 512B. As this rule was not broken when reaching several capacity limitis like LBA28 I expect that it will not be changed in near future. There will be fallback option for 512B sectors that will work slower but better than nothing. But if FD wants to be ready why messing with 2kB sectors and not 4kB? I think that's big difference between 512B and something else but not much between 2k and 4k...

> the future. (Though I think we've got bigger problems with UEFI, but
> anyways ....)

Yes, when UEFI drops BIOS compatability module we get f*cked. And how long will intel keep realmode and x86 instructions?

---
DOS gives me freedom to unlimited HW access.

> * r1702 improve handling for sectors not 512 bytes in size
> (up to 2048 bytes, larger sizes not yet working)
>
> Seems like minor changes except the support for 2048 sectors? Where is it
> used?

As I commented in another mail to that list, the 1702 changes were effectively reversed by 1704, which for some reason isn't noted in that log. 1704 changed the maximum supported sector size back to 512 but left the other preparations done by 1702 (more complicated macro usage, etc) in place.

---
l

> But if FD wants to be ready why messing
> with 2kB sectors and not 4kB? I think that's big difference between 512B
> and something else but not much between 2k and 4k...

Here's something from another mail exchange from the Freedos-kernel list, the earlier inquiry is from my first mail there, the answers are from Jeremy's reply:

> > > - Fourth, apart from the other points, I fail to see why you should not be
> > > able to simply increase MAX_SEC_SIZE to 8192. 4096 is definitely in need
> > > as evidenced by the list's requests for precisely that size.
> >
> > agreed, though currently any value > 3KB causes memory corruption if
> > too many buffers are specified (I have successfully gotten 4KB sectors
> > to finish booting by changing buffers=2).
> >
> > [...]
> >
> > I currently have tracked down part of my issue to allocation problems
> > if buffers is too large, but still working on relearning the init time
> > segment relocations and order to determine a proper fix for buffer
> > allocations. It would help if printf worked correctly in all the init
> > code...

As I commented on the list, this seems like a problem specific to HLL kernel development.

---
l

> Here's something from another mail exchange from the Freedos-kernel list,
> the earlier inquiry is from my first mail there, the answers are from
> Jeremy's reply:

> > > I currently have tracked down part of my issue to allocation problems
> > > if buffers is too large, but still working on relearning the init time

Yes I can understand that if someone set BUFFERS=40 and sectors increased 8x in size then it will simply overflow the segment. But it shouldn't be so hard to add some limiter that will decide max. safe buffer count according to used sector size...

---
DOS gives me freedom to unlimited HW access.

> Yes I can understand that if someone set BUFFERS=40 and sectors increased
> 8x in size then it will simply overflow the segment.

True, if the structure of linked buffers is bound to one segment.

> But it shouldn't be so
> hard to add some limiter that will decide max. safe buffer count according
> to used sector size...

Right. And I was under the impression that the issue here is rather related to some quirks of how memory allocation is handled, hence my comment on HLL development.

---
l

Don't get too excited. Hard drives are going to support 512 byte sectors for a long time, either natively or through emulation on the drive itself. You might have a performance hit if you use emulation on the drive but I don't think that most software is getting the maximum performance out of drives today anyway, so it is a minor issue.

(How many systems running DOS are submitting more than one command to the drive at a time? Answer: 0 ... there is a lot of performance being left on the table as things are.)

The discussion on the FreeDOS mailing list seems a bit hysterical. There is too much existing operating system code, controllers, and software that assumes 512 byte sectors.

(Disclaimer: I work in the industry, but this is my opinion only.)

---
mTCP - TCP/IP apps for vintage DOS machines!
http://www.brutman.com/mTCP

> I don't think that most software is getting the maximum performance out
> of drives today anyway, so it is a minor issue.
>
> (How many systems running DOS are submitting more than one command to the
> drive at a time? Answer: 0 ... there is a lot of performance being left
> on the table as things are.)

Definitely.

> The discussion on the FreeDOS mailing list seems a bit hysterical. There
> is too much existing operating system code, controllers, and software that
> assumes 512 byte sectors.

Oh? I was under the impression that the main motivation for the recent discussion was to support USB devices that specifically do not offer 512B sector emulation. These devices apparently exist today (if uncommon), so some talk on how they might be supported doesn't seem "hysterical" to me.

---
l

> > The discussion on the FreeDOS mailing list seems a bit hysterical.
> There
> > is too much existing operating system code, controllers, and software
> that
> > assumes 512 byte sectors.
>
> Oh? I was under the impression that the main motivation for the recent
> discussion was to support USB devices that specifically do not offer 512B
> sector emulation. These devices apparently exist today (if uncommon), so
> some talk on how they might be supported doesn't seem "hysterical" to me.

That thread started as a discussion of 4K block sizes on rotating magnetic media.

Regardless, I'm encouraged to see the original poster is working on writing code.

---
mTCP - TCP/IP apps for vintage DOS machines!
http://www.brutman.com/mTCP

>> * r1697 from Pete Batard, do not display CHS mismatch warning
>> during booting when forcing LBA mode option set
> Rufus "DOS-on-USB-installer" dude, basically shutting up some scary
> warnings.

I think you mean Pete Batard as in "Rufus - The Reliable USB Formatting Utility with Source" dude. DOS-on-USB is a different project including copyrighted files (which I won't link to). Importantly "From version 1.2.0 (2012.06.04), a single version of Rufus is provided, that includes FreeDOS support." (works well IMHO).

I came across Rufus the other day after deciding to revisit what Windows USB boot disk creators exist, not only for my occasional Windows usage but also in terms of wanting a well written tool that I could point people to and say "use that". I believe that in Rufus that I have found just what I was seeking (I am still testing). Sure many other options exist such as UNetbootin which works well. However regarding the existing options I either have copyright concerns or in the case of UNetbootin technical dislikes, e.g UNetbootin works by always needing to use syslinux. Rufus doesn't appear to have any legal issues or unnecessary syslinux requirements.

Pete gave the background to Rufus in the following blog post: Rufus - The bootable USB Formatting Utility

The rest of Pete Batard's blog is also interesting reading for the technically minded. See also Akeo Consulting's homepage.

[EDIT]
I meant to add that when using Rufus that if you click the down arrow next to formatting options that you can easily set the BIOS ID. Pete covers the why and technical how in this blog post: Crafting an MBR from scratch
See also Rufus (introduction topic) which has a screenshot and extra technical background from Pete (Akeo).
[/EDIT]