DOS ain't dead

Just fyi:

I heard that the new p-6x chipsets from intel don't feature an built-in PCI implementation anymore.

Mobo's using this chipset however sometimes do support PCI, but with PCIex to PCI bridges. (and usually only one or two, since there are finally more PCIex lanes now).

I was reminded by the mention of Audigy-2 in the previous thread, I still have several such cards too.

> Just fyi:
>
> I heard that the new p-6x chipsets from intel don't feature an built-in PCI
> implementation anymore.
>
> Mobo's using this chipset however sometimes do support PCI, but with PCIex
> to PCI bridges. (and usually only one or two, since there are finally more
> PCIex lanes now).
>
> I was reminded by the mention of Audigy-2 in the previous thread, I still
> have several such cards too.

Yes this is the next step close to the famous PC INCOMPATIBLE architecture we are approaching now. See my post below about my new core i5 machine at work. It is based on intel H57 and completly lacks PCI, IDE, FDC, COM, LPT, PS/2... just PCI-E, SATA and USB. Only one step remains - replace BIOS with EFI (EFI may contain BIOS compatibility module but I suspect it would be buggy and slow and quickly disappear).

BTW I have SB Audigy 2 too (few days ago I upgraded from SB live 1024).

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

> famous PC INCOMPATIBLE architecture

??

Well, ISA is gone a long time too, and people complained as hard when the DIN keyboard was exchanged for the PS/2. Or ISA by PCI.

> It is based on intel H57 and
> completly lacks PCI, IDE, FDC, COM, LPT, PS/2... just PCI-E, SATA and USB.

Actually several modern boards have COM pinheaders on the mobo. They are just not connected. The flat-cable with (9 or 25 pins) serial port can be found easily and cheaply (but unfortunately if you order only one, the shipping costs will be magnitudes larger than the price. We need at least one COM per system, so we bought a bunch of them at low cost)

I do miss PS/2 kbd and mouse though. While USB2 kbd/mouse works far better on somewhat recent systems than when it on older systems(*) , the plug and play nature can cause funky behaviour if other devices are plugged in on the bus.

To be honest, I never really liked USB, and avoid it if I reasonably can (e.g. I buy ESATA HDs, and firewire in the past). Basically I only use it for printer and sticks.

Won't miss floppy too. Used one only two times in the last 6-7 years, both times for bios recovery, but this increasingly works with USB thumbdrives too

> Only one step remains - replace BIOS with EFI (EFI may contain BIOS
> compatibility module but I suspect it would be buggy and slow and quickly
> disappear).

I actually can't wait for that to happen. Kills the MBR and finally no primary partition limit (and/or other special partition handling) anymore.
But that is from a *nix perspective.

(*) and still, devices that have mouse+kbd with the same USB plug (nested HID device) often don't work properly preboot.

> Well, ISA is gone a long time too, and people complained as hard when the
> DIN keyboard was exchanged for the PS/2. Or ISA by PCI.

Yes. E.g. can you imagine there are special ISA/PCI adapters for industrial and medical devices, that cost more than whole PC? When mobo fail and you have to buy new one you are missing the interface. You have to pay x-times more for overpriced special industrial mobo (btw it's nothing special, one my friend do with advantech mobo, they cost ~5x than office desktop mobo but some of them fails after 2-3 years like those cheap desktop mobos - same china crap)...
But it's not my case. I just have some favorite HW that I like to use.

> Actually several modern boards have COM pinheaders on the mobo. They are
> just not connected. The flat-cable with (9 or 25 pins) serial port can be
> found easily and cheaply (but unfortunately if you order only one, the
> shipping costs will be magnitudes larger than the price. We need at least
> one COM per system, so we bought a bunch of them at low cost)

Hm, I was looking on various core iX mobos and didn't saw such pin headers. Only for USB. I belive that superIO chip may still contain neened pins but they are lazy to route pins out. Can you show me such mobo (not industrial)?
I know about one Gigabyte that has even DSUB9&25 for COM&LPT on backside.

> I do miss PS/2 kbd and mouse though. While USB2 kbd/mouse works far better
> on somewhat recent systems than when it on older systems(*) , the plug and
> play nature can cause funky behaviour if other devices are plugged in on
> the bus.

USB KB/mouse support (and USB flashdisk) is done via BIOS emulation and there are some programs that crashes with it. E.g. Uniflash in some cases. So if it would be 100% transparent emulation I don't complain.

> To be honest, I never really liked USB, and avoid it if I reasonably can
> (e.g. I buy ESATA HDs, and firewire in the past). Basically I only use it
> for printer and sticks.

I also don't like it. BTW did you e.g. tried to connect 4 or more serial/usb convertor to USB hub and collect simultaneously sent data streams? Many USB hubs will fail and drop some data. You need to figure out which ports will work together and maybe you end up with less than 4 working.
I also do alot with MCU and have a lot of gadgets to COM/LPT ports because this is simle interface that you can implement on MCU side and also control SW on PC consist of a few outportb() instead of handling USB evil...
Also ISA was good for this case. I can made simple ISA card at home with common parts from 74xx logic but I probably cannot do it for PCI (but still possible) and surely not for PCI-E.

> Won't miss floppy too. Used one only two times in the last 6-7 years, both
> times for bios recovery, but this increasingly works with USB thumbdrives
> too

I still use floppy. Sometimes for booting various OS that I want to try and also for transfering data from older spectrum analyser (it costed ~4x than office PC so I don't accept idea trash it and buy new one). Fortunatelly there are also USB floppies...

> I actually can't wait for that to happen. Kills the MBR and finally no
> primary partition limit (and/or other special partition handling) anymore.
> But that is from a *nix perspective.

I didn't reach 2TB prolem so don't care yet. BUT it's not about MBR, it's about BIOS services. If there will not be BIOS you cannot boot DOS. Modern OS like MACOS can use EFI for loading but who will rewrite DOS? This is what I call end of IBM PC compatible. Well it is still x86 but completly without legacy support stuff.

BTW any idea why VESA LFB access is so slow on that PC?

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

> > Well, ISA is gone a long time too, and people complained as hard when
> the
> > DIN keyboard was exchanged for the PS/2. Or ISA by PCI.
>
> Yes. E.g. can you imagine there are special ISA/PCI adapters for industrial
> and medical devices, that cost more than whole PC?

Duh, same as the search by Nasa for 80(1)86's.

> When mobo fail and you
> have to buy new one you are missing the interface. You have to pay x-times
> more for overpriced special industrial mobo (btw it's nothing special,

No, since I did the smart thing and junked that kind of kit long ago. Sure, if it is your NMR, you might have no choice, but you are not very likely to run new software on your NMR.

> > Actually several modern boards have COM pinheaders on the mobo. They are
> > just not connected. The flat-cable with (9 or 25 pins) serial port can
> be
> > found easily and cheaply (but unfortunately if you order only one, the
> > shipping costs will be magnitudes larger than the price. We need at
> least
> > one COM per system, so we bought a bunch of them at low cost)
>
> Hm, I was looking on various core iX mobos and didn't saw such pin headers.

As said, our current Gigabyte P6* series mobo has. So new that it is buggy!

I can lookup exact type tomorrow, but it has the flawed *6* series chip, so might be hard to get (we ordered just before the recall)

> > I do miss PS/2 kbd and mouse though. While USB2 kbd/mouse works far
> better
> > on somewhat recent systems than when it on older systems(*) , the plug
> and
> > play nature can cause funky behaviour if other devices are plugged in on
> > the bus.
>
> USB KB/mouse support (and USB flashdisk) is done via BIOS emulation and
> there are some programs that crashes with it. E.g. Uniflash in some cases.
> So if it would be 100% transparent emulation I don't complain.

(It is the PNP nature, and the timeouts for busreset, rather than USB itself I suspect)

> > To be honest, I never really liked USB, and avoid it if I reasonably can
> > (e.g. I buy ESATA HDs, and firewire in the past). Basically I only use
> it
> > for printer and sticks.
>
> I also don't like it. BTW did you e.g. tried to connect 4 or more
> serial/usb convertor to USB hub and collect simultaneously sent data
> streams?

No. I never actually got serial/usb connectors to run reliably long term.

I use some for the admin ports of some of our hardware, and we use them with laptops for testing. But we always get real ports for production machines.

I would already be happy if they were just flawed and unreliable. I suspect several of them of messing with hibernation behaviour of said laptops.

Luckily PCI (or PCIex) versions of com cards are relatively cheap. (I actually bought 6 for Eur 15 together a while back)

> I also do alot with MCU and have a lot of gadgets to COM/LPT ports because
> this is simle interface that you can implement on MCU side and also control
> SW on PC consist of a few outportb() instead of handling USB evil...

Well, we use windows (and more rarely *nix) for production machines. But indeed, no USB there. Trust COM port cards all the way. Connect to Uc boards.

> Also ISA was good for this case. I can made simple ISA card at home with
> common parts from 74xx logic but I probably cannot do it for PCI (but still
> possible) and surely not for PCI-E.

Well, ISA was mostly out of production when I entered the workfloor in 2000.


> > I actually can't wait for that to happen. Kills the MBR and finally no
> > primary partition limit (and/or other special partition handling)
> anymore.
> > But that is from a *nix perspective.
>
> I didn't reach 2TB prolem so don't care yet.

I have hit the 3/4 primary partition limit often enough.

> BUT it's not about MBR, it's
> about BIOS services.

It's also partitionlabel layout.

> If there will not be BIOS you cannot boot DOS.

Couldn't care less. And while I have several XP/32 machines, I wouldn't install XP on new machines, so that is not a problem.

> Modern OS like MACOS

(I assume you mean OSX. if sb says MACOS I still think of classic macos, preferably on 68k)

> can use EFI for loading but who will rewrite DOS? This is
> what I call end of IBM PC compatible.

Thank god!

> Well it is still x86 but completly without legacy support stuff.

About time!

> BTW any idea why VESA LFB access is so slow on that PC?

Nobody cares for accelerating it anymore. It is only used for GUIs during OS install, and after people go to native emulation. For that "compatibility" situation it doesn't have to be fast. The Linux fora are full of thread how to get rid of "generic vesa", and move to native ATI/NVIDIA/Intel drivers as quick as possible

> No, since I did the smart thing and junked that kind of kit long ago. Sure,
> if it is your NMR, you might have no choice, but you are not very likely to
> run new software on your NMR.

3 years ago I assisted with building a new PC for a dentist who needed to run his digital x-ray machine that used some special ISA adapter. I also have a friend in FCC PS which sells industrial PCs and ISA is still sometimes used. And PCI a very lot. It's not fun comlpetly remake some old but well running industrial systems. Many people may call me a conservative but I have respect to that well designed and long time running machines...

> I can lookup exact type tomorrow, but it has the flawed *6* series chip,
> so might be hard to get (we ordered just before the recall)

OK, let me know. I was talking about this one:

GIGABYTE P55-UD3L

This is one and only in the shop offer

> (It is the PNP nature, and the timeouts for busreset, rather than USB
> itself I suspect)

I don't know but I suspect the code. It should run in SMI mode so should be transparent but it may introduce some delays or there maybe some bugs that cause SW to crash... So if I can choose I get PS/2 KB and disable USB emulation.

> No. I never actually got serial/usb connectors to run reliably long term.

I use some with FTDI232 and Prolific PL2302. Single seems to work usable but when we measured various GPS receivers connected to USB HUB it was relly pain. We do outdoor test so it was connected to notebook where was not any real serial and no choice for expansion

> Luckily PCI (or PCIex) versions of com cards are relatively cheap. (I
> actually bought 6 for Eur 15 together a while back)

Yes that's cheap. We bougt combo 2xCOM + 1xLPT PCI-E 1x at work for about 500 CZK ~ 20euro. It works fine under win/linux. But it uses exotic IO base so DOS programs cannot find them and coz of PnP I cannot force them to usual low address. But I don't need it at work only at home.

> I have hit the 3/4 primary partition limit often enough.

And you really need to make them primary? Cannot be in extended? I run multiple OSes dos/win/linux and have enough 3 primary + 1 extended...

> (I assume you mean OSX. if sb says MACOS I still think of classic macos,
> preferably on 68k)

Oh yes, OSX...

> > can use EFI for loading but who will rewrite DOS? This is
> > what I call end of IBM PC compatible.
>
> Thank god!

Hmm, then why you're loosing time on DOS forum with oldskool fanatics rather than polishing your 64bit super hyper modern bloatware windows/linux

> Nobody cares for accelerating it anymore. It is only used for GUIs during
> OS install, and after people go to native emulation. For that

But it's not about any HW acceleration. VESA LFB is just a piece gfx memory mapped into CPU address space. So why it's now 100x slower? New PCI-E bus allows transfer GB/s but someone crippled that.

> "compatibility" situation it doesn't have to be fast. The Linux fora are
> full of thread how to get rid of "generic vesa", and move to native
> ATI/NVIDIA/Intel drivers as quick as possible

Yes linux VESA framebuffer is also affected. You can replace it with something called a "driver" (nouveau) but then it will not be universal. VESA stuff is good for various live CD when you don't know the specific target machine but you know that in this days it has 99,99% VGA card with VESA VBE that alloews you use graphics on some basic level. Without it you need fallback to VGA or provide specific drivers for different VGA card but you still couldn't cover the future models. So VESA is good for basic system.
And also for those who still write some graphics code under DOS or their alternative mini OS. Belive or not such people still lives

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

> > No, since I did the smart thing and junked that kind of kit long ago.
> Sure,
> > if it is your NMR, you might have no choice, but you are not very likely
> to
> > run new software on your NMR.
>
> 3 years ago I assisted with building a new PC for a dentist who needed to
> run his digital x-ray machine that used some special ISA adapter. I also
> have a friend in FCC PS which sells industrial PCs and ISA is still
> sometimes used. And PCI a very lot. It's not fun comlpetly remake some old
> but well running industrial systems. Many people may call me a conservative
> but I have respect to that well designed and long time running machines...

I know all about it. But staying to conservative too long is not healthy either. The big gaps in technology then kill you. Throwing some money at it to keep old stuff running can then be the easy way, but is not always the smartest.

> > I can lookup exact type tomorrow, but it has the flawed *6* series
> chip,
> > so might be hard to get (we ordered just before the recall)
>
> OK, let me know. I was talking about this one:
>
> GIGABYTE
> P55-UD3L
>
> This is one and only in the shop offer

Gigabyte H67M-D2 (for socket LGA1155, the new Sandy Bridge CPUs) has two COM sockets. It also has PS/2.

> > No. I never actually got serial/usb connectors to run reliably long
> term.
>
> I use some with FTDI232 and Prolific PL2302. Single seems to work usable
> but when we measured various GPS receivers connected to USB HUB it was
> relly pain. We do outdoor test so it was connected to notebook where was
> not any real serial and no choice for expansion

The driver that I said was prolific iirc.

> > Luckily PCI (or PCIex) versions of com cards are relatively cheap. (I
> > actually bought 6 for Eur 15 together a while back)
>
> Yes that's cheap. We bougt combo 2xCOM + 1xLPT PCI-E 1x at work for about
> 500 CZK ~ 20euro. It works fine under win/linux. But it uses exotic IO base
> so DOS programs cannot find them and coz of PnP I cannot force them to
> usual low address. But I don't need it at work only at home.
>
> > I have hit the 3/4 primary partition limit often enough.
>
> And you really need to make them primary?

Yes.

> Cannot be in extended?

Not always, and when even when it should work in theory, it doesn't always work. (because of "smart" auto-partitioning programs)

> multiple OSes dos/win/linux and have enough 3 primary + 1 extended...

How do you boot a dos partition in the extended partition? Windows is even worse. While old NT4 had a way to have a separate bootmgr, afaik this doesn't exist anymore (and if it does, it eats an extra paritition).

And the bootmgr now is part of HD0, active partition, period.

> Hmm, then why you're loosing time on DOS forum with oldskool fanatics
> rather than polishing your 64bit super hyper modern bloatware windows/linux
>

I sometimes wonder too But I'm mainly here because of interest in fullscreen textmode apps. Something that is simply more happening on Dos, but works absolutely fine on 64bit super hyper modern bloatware windows/linux/BSD/OSX

> > Nobody cares for accelerating it anymore. It is only used for GUIs
> during
> > OS install, and after people go to native emulation. For that
>
> But it's not about any HW acceleration. VESA LFB is just a piece gfx memory
> mapped into CPU address space. So why it's now 100x slower? New PCI-E bus
> allows transfer GB/s but someone crippled that.

Because it is not properly initialized, and nobody cares since the onesit is only used for the minimal stuff

Search for Coreboot (the open source bios, with wonderful functionality as minimal OSes in the BIOS), they IIRC have a nice writeup over what happens when the PC boots.

> > "compatibility" situation it doesn't have to be fast. The Linux fora are
> > full of thread how to get rid of "generic vesa", and move to native
> > ATI/NVIDIA/Intel drivers as quick as possible
>
> Yes linux VESA framebuffer is also affected. You can replace it with
> something called a "driver" (nouveau) but then it will not be universal.

But universal is only required for installation. Maybe a bit rescue with a live system at best (but they already have drivers for ATI and Nvidia, like nouveau)

> VESA stuff is good for various live CD when you don't know the specific
> target machine but you know that in this days it has 99,99% VGA card with
> VESA VBE that alloews you use graphics on some basic level. Without it you
> need fallback to VGA or provide specific drivers for different VGA card but
> you still couldn't cover the future models. So VESA is good for basic
> system

It _would_ be good yes. But nobody on Linux is interested in that, since better drivers (nouveau or the old nv) exist. The trend is to pull this even more into the kernel (kernel mode switching recognizes the exact card)

> And also for those who still write some graphics code under DOS or their
> alternative mini OS. Belive or not such people still lives

But nobody _designs_ for DOS requirements anymore. The group is simply too small. (maybe one or two specialised industrial producers excluded, but they will have a relatively old and narrow set of products for extortionist prices, the reason why we don't buy our industrial PCs there)

That is my point. It has no point to say that it could be cared for, or that there are still people that use it. It is not a factor in development of new hardware or its software (read: bios), and hasn't been for years, and what's left from Dos bios support is a result of inertia, and it will only become less.

Holy f*ck, I was auto-logged out during writting a long reply and it didn't posted and got lost, fortunatelly most I recovered via Read&Write utility dumping physmem, it still was in RAM...

> I know all about it. But staying to conservative too long is not healthy
> either. The big gaps in technology then kill you. Throwing some money at it
> to keep old stuff running can then be the easy way, but is not always the
> smartest.

Hm it's golder rule of nowdays economy, make faster, sell more, shorter (managed) lifetime, but it couldn't be shortened to zero, this is highway to hell... But I agree it's good to track new technologies. But it's becoming more and more complicated so you cannot understand it all to the lowest level...

> Gigabyte H67M-D2 (for socket LGA1155, the new Sandy Bridge CPUs) has two
> COM sockets. It also has PS/2.

Thanks. Unfortunatelly it doesn't have any PCI :( BTW did you read about serious bug in intel 6x series chipset? One transistor with too thin gate at high potencial causing excessive leak can disable bot SATA3 ports within few months of use. Intel will replace this chipsets with new revision and you should be able to got free mobo replacement.

> How do you boot a dos partition in the extended partition? Windows is even
> worse. While old NT4 had a way to have a separate bootmgr, afaik this
> doesn't exist anymore (and if it does, it eats an extra paritition).

I don't boot DOS from ext. partition. But I have it on 1st primary FAT16 with other OSes. I have installed WinXP NTLDR that boots:
-WinXP on another primary partition
-WinNT 4.0 on 1st primary
-Win98SE + MSDOS 7.1 on 1st primary via DOS boot sector image
-MSDOS 6.22 on 1st primary via DOS boot sector image
-Linux on another primary partition started from DOS via linld
I have also 2nd HDD with freedos and backup of Win98 and NT4.

> I sometimes wonder too But I'm mainly here because of interest in
> fullscreen textmode apps. Something that is simply more happening on Dos,
> but works absolutely fine on 64bit super hyper modern bloatware
> windows/linux/BSD/OSX

So you mean win32 console apps because DOS console apps doesn't run on x64 because of lack of NTVDM (only via regular emulator)...

> Because it is not properly initialized, and nobody cares since the onesit
> is only used for the minimal stuff

I must figured how. on previous system it was the same problem becuse MTRR regs was not set. I wrote utility to setup it that worked fine on range of old pentiums to new core 2 systemes but this doesn't have effect on core i3/5/7.

> Search for Coreboot (the open source bios, with wonderful functionality as
> minimal OSes in the BIOS), they IIRC have a nice writeup over what happens
> when the PC boots.

One friend code for coreboot I'll ask him but he's AMD fan. AFAIK coreboot did not met this newest HW, they support more older well documented HW.

> But universal is only required for installation. Maybe a bit rescue with a

But idea of live CD is not installation it should run on most of different HW instantly, even without network connection for downloading new drivers.

> It _would_ be good yes. But nobody on Linux is interested in that, since
> better drivers (nouveau or the old nv) exist. The trend is to pull this
> even more into the kernel (kernel mode switching recognizes the exact
> card)

And this makes it bloat. Can you imagine a single boot floppy filled with all different framebuffer drivers? Even if you fit in it will support current VGA but not future. VESA will do until it will disappear.

> The group is simply too
> small. (maybe one or two specialised industrial producers excluded, but
> they will have a relatively old and narrow set of products for extortionist
> prices, the reason why we don't buy our industrial PCs there)
>
> That is my point. It has no point to say that it could be cared for, or
> that there are still people that use it. It is not a factor in development
> of new hardware or its software (read: bios), and hasn't been for years,
> and what's left from Dos bios support is a result of inertia, and it will
> only become less.

Yes but it's my hobby like someone else care about his C64/Atari/Amiga... but seems 8-bit community is larger now...

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

> Hm it's golder rule of nowdays economy, make faster, sell more, shorter
> (managed) lifetime, but it couldn't be shortened to zero, this is highway
> to hell... But I agree it's good to track new technologies. But it's
> becoming more and more complicated so you cannot understand it all to the
> lowest level...

It's always been that way. But the cycles are indeed awfully short nowadays.

> > Gigabyte H67M-D2 (for socket LGA1155, the new Sandy Bridge CPUs) has
> two
> > COM sockets. It also has PS/2.
>
> Thanks. Unfortunatelly it doesn't have any PCI :(

Aargh indeed. Yes, for work purposes we only have once type of PCI card that we use, and we use that only rarely. Most stuff has been converted to PCIexpress. We were relatively early with that because we need multiple (full speed capable) Gigabit links in a machine. Something you can't get with PCI

> BTW did you read about
> serious bug in intel 6x series chipset? One transistor with too thin gate
> at high potencial causing excessive leak can disable bot SATA3 ports within
> few months of use. Intel will replace this chipsets with new revision and
> you should be able to got free mobo replacement.

Yes. But Intel replaces chips to Gigabyte. Moreover currently we can get perfectly by using the SATA6 ports.

> > I sometimes wonder too But I'm mainly here because of interest in
> > fullscreen textmode apps. Something that is simply more happening on
> Dos,
> > but works absolutely fine on 64bit super hyper modern bloatware
> > windows/linux/BSD/OSX
>
> So you mean win32 console apps because DOS console apps doesn't run on x64
> because of lack of NTVDM (only via regular emulator)...

I mostly run win64 binaries on x64. Not because there is a technical reason, but if people don't use it, the FPC win64 port will never get mature.

I killed off all Dos use on normal windows systems in 2002-2003 when I moved to Win2000. (Since dos fullscreen apps are much slower on NT than win32 stuff)

The Pascal exes hardly hurt, it was simply a recompile. The 16-bit modula-2 ones did hurt, but I took the opportunity to clean out the cob webs (the LFN workarounds and detections, the 64k and 640k limit workarounds etc etc)

Most of these programs were in the realms of file indexing, mass renaming, and the more involved ones did logfile processing. The biggest app was never ported because the application whose logfile it processed had died out.

> One friend code for coreboot I'll ask him but he's AMD fan. AFAIK coreboot
> did not met this newest HW, they support more older well documented HW.

True.

> > But universal is only required for installation. Maybe a bit rescue with
> a
>
> But idea of live CD is not installation it should run on most of different
> HW instantly, even without network connection for downloading new drivers.

Yes, but there are only three major videocard vendors. Ati/AMD, Nvidia and intel. Most live systems have them onboard.

> > It _would_ be good yes. But nobody on Linux is interested in that, since
> > better drivers (nouveau or the old nv) exist. The trend is to pull this
> > even more into the kernel (kernel mode switching recognizes the exact
> > card)
>
> And this makes it bloat.

Sorry. The word bloat is meaningless without context, since it is a relative term, and it is not clear in what context. A Full Live DVD typically (because of its compressed filesystem) in the range of 6GB of binaries.

> Can you imagine a single boot floppy filled with
> all different framebuffer drivers? Even if you fit in it will support
> current VGA but not future. VESA will do until it will disappear.

Floppy? Which live CD still boots from floppy? They all moved to IDE emulation years ago (IIRC Slackware 8.1 is the last major linux distro with 2.88MB floppy emulation.

f you mean dos, see below (quoted remarks. Nobody still builds BIOSes with 1997 in mind. You might think that is wrong. I might think that it is wrong (also for my non-dos purposes a more fully featured VESA would be a good thing), but that is simply the way it is.

> > The group is simply too
> > small. (maybe one or two specialised industrial producers excluded, but
> > they will have a relatively old and narrow set of products for
> extortionist
> > prices, the reason why we don't buy our industrial PCs there)
> >
> > That is my point. It has no point to say that it could be cared for, or
> > that there are still people that use it. It is not a factor in
> development
> > of new hardware or its software (read: bios), and hasn't been for years,
> > and what's left from Dos bios support is a result of inertia, and it
> will
> > only become less.
>
> Yes but it's my hobby like someone else care about his C64/Atari/Amiga...
> but seems 8-bit community is larger now...

No problem, but the point I was trying to make is that the C=64/Amiga community doesn't expect current vendors to tailor to their wishes. It is the desire and illusion to run old software on new hardware ad infinitum that causes the (self inflicted) pain.

That is self delusional. Like the C=64 community, the dos community must stop whining and take charge itself, since there is nothing to be expected from PC vendors despite the similarity of new computers to the old ones dos used to run on. This similarity has been a blessing, but is at the slowly getting a curse since it provides no clean break where people say "now we have to fend for our own", and tempts people to try to prolong it just a little bit longer. That together with the fact that Dos itself doesn't evolutes is hopeless.

The linux community builds own ARM and MIPS hardware and phones.

> I killed off all Dos use on normal windows systems in 2002-2003 when I
> moved to Win2000. (Since dos fullscreen apps are much slower on NT than
> win32 stuff)

Except for LZMA-FPC, I've never seen any significant slowdown with 32-bit DOS apps. So nyah.

DJGPP is (apparently) more stable than most others, though, probably due to NTVDM bugs they worked around.

> > And this makes it bloat.
>
> Sorry. The word bloat is meaningless without context, since it is a
> relative term, and it is not clear in what context. A Full Live DVD
> typically (because of its compressed filesystem) in the range of 6GB of
> binaries.

Home users never needed 4 GB before, and I doubt they need it now. That is bloat. Something is wrong when you need that much RAM. And an OS should never need even 1 GB of space for itself. A gigabyte is a lot of space.

> > Yes but it's my hobby like someone else care about his
> C64/Atari/Amiga...
> > but seems 8-bit community is larger now...
>
> No problem, but the point I was trying to make is that the C=64/Amiga
> community doesn't expect current vendors to tailor to their wishes. It is
> the desire and illusion to run old software on new hardware ad infinitum
> that causes the (self inflicted) pain.

Blame Intel for the 386 (V86 mode). Blame MS and Bill Gates for calling the 286 "braindead" for lacking it. Blame PharLap and Borland and Watcom and DJGPP for bringing DOS extenders to the masses. Blame DOSEMU (even x86-64), FreeDOS, DOSBox for giving free alternatives. And blame MS for Win9x (DOS-based) and WinNT supporting NTVDM at all (despite bugs they refused to fix). Blame those who wrote all those famous DOS apps (Desqview, MASM, TP/BP, Doom). Blame DOSMinix and old Linux 2.4's UMSDOS. And blame those who still sell DOS software (esp. games, Gog.com or Sierra or id).

> That is self delusional. Like the C=64 community, the dos community must
> stop whining and take charge itself, since there is nothing to be expected
> from PC vendors despite the similarity of new computers to the old ones dos
> used to run on. This similarity has been a blessing, but is at the slowly
> getting a curse since it provides no clean break where people say "now we
> have to fend for our own", and tempts people to try to prolong it just a
> little bit longer. That together with the fact that Dos itself doesn't
> evolutes is hopeless.

MS thinks you can just (re)buy everything. Linux thinks you can just (re)compile everything. Mac doesn't care, they deprecate faster than anyone. According to popular opinion, no other OS matters (not even your precious FreeBSD, sorry). So it's all a losing battle (or constant war) anyways.

> And blame MS for Win9x (DOG-based)

I do

> and WinNT supporting NTVDM at all

I do

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

> > And blame MS for Win9x (DOG-based)
>
> I do

I like it (still have it installed).

> > and WinNT supporting NTVDM at all
>
> I do

I like it (still have it installed).

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

> I like it (still have it installed).
> I like it (still have it installed).

Use DBAN

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

> > I killed off all Dos use on normal windows systems in 2002-2003 when I
> > moved to Win2000. (Since dos fullscreen apps are much slower on NT than
> > win32 stuff)
>
> Except for LZMA-FPC, I've never seen any significant slowdown with 32-bit
> DOS apps. So nyah.

Note that I noted fullscreen. Dos textwindowing seemed to be (much) slower on winNT than using windows read/writeconsole functions.


> > Sorry. The word bloat is meaningless without context, since it is a
> > relative term, and it is not clear in what context. A Full Live DVD
> > typically (because of its compressed filesystem) in the range of 6GB of
> > binaries.
>
> Home users never needed 4 GB before, and I doubt they need it now.

Who are you to say what they need? The last time I checked they happily bought 2TB discs. I didn't see one asking the stewards if they have some older 200MB lying around, because 2TB is such a terribly bloatty thing to do.

> That is
> bloat.

That's what you like the call bloat yes. But that is your problem

> Something is wrong when you need that much RAM. And an OS should
> never need even 1 GB of space for itself. A gigabyte is a lot of
> space.

Strangely enough I agree with you there mostly. Specially if you compare Win2000 to later variants (that don't add THAT much).

But while I agree, I don't make such issues the center of my universe to justify any nostalgic feelings that I might have.

> > No problem, but the point I was trying to make is that the C=64/Amiga
> > community doesn't expect current vendors to tailor to their wishes. It
> is
> > the desire and illusion to run old software on new hardware ad infinitum
> > that causes the (self inflicted) pain.
>
> Blame Intel for the 386 (V86 mode). Blame MS and Bill Gates for calling the
> 286 "braindead" for lacking it. Blame PharLap and Borland and Watcom and
> DJGPP for bringing DOS extenders to the masses. Blame DOSEMU (even x86-64),
> FreeDOS, DOSBox for giving free alternatives. And blame MS for Win9x
> (DOS-based) and WinNT supporting NTVDM at all (despite bugs they refused to
> fix). Blame those who wrote all those famous DOS apps (Desqview, MASM,
> TP/BP, Doom). Blame DOSMinix and old Linux 2.4's UMSDOS. And blame those
> who still sell DOS software (esp. games, Gog.com or Sierra or id).

I don't see why? They wrote it, released it, and served their warranty period. The users that still use it are now responsible for it themselves.

But they are reluctant to take that responsibility, and prefer to nag how everybody left them behind to operate ridiculously bloated systems, and not much new happens.

At the same time, the even older Commodore oldtimers are trying to recreate their old systems using FPGA means.

See the difference?

> > That is self delusional. Like the C=64 community, the dos community must
> > stop whining and take charge itself, since there is nothing to be
> expected
> > from PC vendors despite the similarity of new computers to the old ones
> dos
> > used to run on. This similarity has been a blessing, but is at the
> slowly
> > getting a curse since it provides no clean break where people say "now
> we
> > have to fend for our own", and tempts people to try to prolong it just a
> > little bit longer. That together with the fact that Dos itself doesn't
> > evolutes is hopeless.
>
> MS thinks you can just (re)buy everything. Linux thinks you can just
> (re)compile everything. Mac doesn't care, they deprecate faster than
> anyone. According to popular opinion, no other OS matters (not even your
> precious FreeBSD, sorry). So it's all a losing battle (or constant war)
> anyways.

Probably. But that was not the point. If you want to resist it, what are you (and the dos community at large) going to do about it except nagging and whining?

The other nostalgic groups are creating their own hardware platforms as contigency. I don't see any efforts in the Dos community. (or any form of organization other than DJGPP for that matter)

Since otherwise Dos on new hardware will die very abruptly if e.g. the BIOS or 32- bit mode disappears. And while EFI might incorporate a legacy bios for a while, when that stops to be commercial interesting (read: XP and other 32-bit versions are totally irrelevant), it will be essentially unmaintained. And way buggier than current bios, since that at least uses certain compatibility modes for the booting process, that will then go through native EFI modes.

> Most stuff has been converted to
> PCIexpress. We were relatively early with that because we need multiple
> (full speed capable) Gigabit links in a machine. Something you can't get
> with PCI

Do you have experiences with some PCI-E to PCI converters or somewhere I saw a PCI-E chip with parallel output interface that was simply programmed by few registers. There should be something similar for implementing MMIO but I never come closer to it.

> Yes. But Intel replaces chips to Gigabyte. Moreover currently we can get
> perfectly by using the SATA6 ports.

AFAIK new revision will be upgraded within a month and then it will take some time for manufacturers to replace it. Yes you can live with other SATA port but I wouldn't like the feeling that something is rotting in the chip...

> I mostly run win64 binaries on x64. Not because there is a technical
> reason, but if people don't use it, the FPC win64 port will never get
> mature.

And does your 64bit application got some significant benefit from 64bit platform, e.g. in data throughput or it's just ~2x bigger binary working +-few % the same as 32bit?

> Yes, but there are only three major videocard vendors. Ati/AMD, Nvidia and
> intel. Most live systems have them onboard.

Maybe, but different chip generations of one vendor are usually not compatible so when they release new generation chip (e.g. GeForce 7xxx -> 8xxx) you'll have to upgrade driver on your live CD. So it's better to have one simple standard and keep it in future.

> Sorry. The word bloat is meaningless without context, since it is a
> relative term, and it is not clear in what context. A Full Live DVD
> typically (because of its compressed filesystem) in the range of 6GB of
> binaries.

I was thinking about live CDs on mini 8cm disk. There's about 200MB. I think it's better to stuff it with usefull utilities then fill it entirely with different drivers levanig space only for bares hell.

> Floppy? Which live CD still boots from floppy? They all moved to IDE
> emulation years ago (IIRC Slackware 8.1 is the last major linux distro with
> 2.88MB floppy emulation.

I think there are still some (maybe obscure) single 1.44 or 2.88 floppu mini distros.

> (also for my non-dos purposes a more fully featured VESA would be a good
> thing), but that is simply the way it is.

Hm here you say that you would find usefull "more fully featured VESA" but from your previous write I got feeling that you want to kill ALL the legacy stuff, little bit inconsistent. Of course I understand there's now difference between my wishes and reality and I cannot do much more with it (except supportinig some obscure openHW/openFW projects).

> No problem, but the point I was trying to make is that the C=64/Amiga
> community doesn't expect current vendors to tailor to their wishes. It is
> the desire and illusion to run old software on new hardware ad infinitum
> that causes the (self inflicted) pain.

But C64/Amiga never aspired to became wide and long computer standard as PC. The PC compatible was set this standard and now it's leaving it. So I think it's time for raneming the whole architecture...

> That is self delusional. Like the C=64 community, the dos community must
> stop whining and take charge itself, since there is nothing to be expected
> from PC vendors despite the similarity of new computers to the old ones dos
> used to run on. This similarity has been a blessing, but is at the slowly
> getting a curse since it provides no clean break where people say "now we
> have to fend for our own", and tempts people to try to prolong it just a
> little bit longer. That together with the fact that Dos itself doesn't
> evolutes is hopeless.

Yes maybe it would was better that MSDOS was forgotten when 386 was introduced (before I got PC) and e.g. OS/2 was spreaded instead it. We would bring us much brighter future. But it didn't happened so and there spreaded a lot of DOS apps that I like. Maybe as you said the sharp break would be bettes. Even intel probably planned it with itanium IA64 which missing x86 (or poorly emulated) but it didn't become standard.

> The linux community builds own ARM and MIPS hardware and phones.

I know. I was also thinking about something like that, make openHW PC (probably FPGA based) supporting all good standards of DOS day. But as my student time has ended I will never have enough time to realize it. Maybe some chinese guys will come with such portable emulating DOS games/demos engine :)

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

>> I killed off all Dos use on normal windows systems in 2002-2003 when I
>> moved to Win2000. (Since dos fullscreen apps are much slower on NT than
>> win32 stuff)

> Except for LZMA-FPC, I've never seen any significant slowdown with 32-bit
> DOS apps. So nyah.

I would not have mentioned the following in a DOS forum, but you kinda started me... For CPU bound apps, NTVDM indeed is awfully slow - independent of display mode.

A craftfuly enough optimised program of mine doing heavy and lengthy calculations during hours, entirely in registers (avoiding memory accesses, even from the data caches!), runs about 4 times slower -wall time- in Windows 2k than in pure DOS ! And this is in concurrence with NO other (user) tasks ! And running maximised in foreground (just in case, but no joice).

The cause is, of course, you cannot stop Windows multitasking°, and it consumes 3 times more time doing whatever obscure and (in this case) evidently useless bookkeeping just in order to stay alive!!!
(edit) sorry I forgot to stress, another cause to this extreme slowdown is that every context switch disrupts caches thus ruining the optimisation I mentionned (edit ends)

° Or can you ? I did some research, even asked the Sysinternals gurus, never found any way to "tame" the beast, albeit means to increase the time quantum alloted to the task of interest. Oddly, it's possible to decrease the quantum (for "multimedia" purposes. burp!)

Under the virtual DOS box of Windows 9x, the slowdown if much less than NT, but still significant (unbearable for the lengthy calculations). Except of course unlike NT you /could/ CLI under 9x ;=)

One more reason to keep our DOS living !

---
Ninho

> > Most stuff has been converted to
> > PCIexpress. We were relatively early with that because we need multiple
> > (full speed capable) Gigabit links in a machine. Something you can't get
> > with PCI
>
> Do you have experiences with some PCI-E to PCI converters or somewhere I
> saw a PCI-E chip with parallel output interface that was simply programmed
> by few registers. There should be something similar for implementing MMIO
> but I never come closer to it.

Aside from the already mentioned use on the new p67 generation boards (because they don't support PCI in the base chipset), I can vaguely remember somebody mentioning HP SFF pc's (the HP 7xxxdc series) using them for their riser cards. I didn't verify that though.

> > Yes. But Intel replaces chips to Gigabyte. Moreover currently we can get
> > perfectly by using the SATA6 ports.
>
> AFAIK new revision will be upgraded within a month and then it will take
> some time for manufacturers to replace it. Yes you can live with other SATA
> port but I wouldn't like the feeling that something is rotting in the
> chip...

True. And if we see a chance to quickly replace it, we will. But the main objective to buy it was to start testing so we can deploy these boards (or their fixed versions) in the field.

Well, turns out there is no real hurry, since while the integrated GPU is praised in all publications, it is still 5+ times slower than the cheapest ati or nvidia card, and we are not terribly pricesensitive there.

> > I mostly run win64 binaries on x64. Not because there is a technical
> > reason, but if people don't use it, the FPC win64 port will never get
> > mature.
>
> And does your 64bit application got some significant benefit from 64bit
> platform, e.g. in data throughput or it's just ~2x bigger binary working
> +-few % the same as 32bit?

No. At work I would have some uses for it (mainly the double SSE registers), but for the FPC work it doesn't matter atm. But there the goal is to debug a 64-bit toolchain, and to do so, you must use it to find all the little problems and bugs.

Another big advantage of 64-bit is that the minimal CPU gets lifted to something Pentium-D like. This simplifies compilers considerably. copro is always integrated, ppro instructions (cmov) are, and SSE2 is always there (and SSE3 too if you are not too strict)

Since this is the first real deprecation of old stuff since the i386 came out in 1988 or so, that is a major thing. (though most people only started to really use the 386 in 95-97 with the advent of Windows 9x and cheaper memory)

> > Yes, but there are only three major videocard vendors. Ati/AMD, Nvidia
> and
> > intel. Most live systems have them onboard.
>
> Maybe, but different chip generations of one vendor are usually not
> compatible so when they release new generation chip (e.g. GeForce 7xxx ->
> 8xxx) you'll have to upgrade driver on your live CD.

For me it usually worked. My fairly new ATI 5770 worked fine with 4xxx drivers.

> So it's better to have one simple standard and keep it in future.

Even if so, it is irrelevant, since nobody cares. VESA implementations of laptops are often even worse then from videocards btw.

> > Sorry. The word bloat is meaningless without context, since it is a
> > relative term, and it is not clear in what context. A Full Live DVD
> > typically (because of its compressed filesystem) in the range of 6GB of
> > binaries.
>
> I was thinking about live CDs on mini 8cm disk. There's about 200MB. I
> think it's better to stuff it with usefull utilities then fill it entirely
> with different drivers levanig space only for bares hell.

I haven't seen mini disks for sale in ages, and when I did they were more expensive than white label DVDs. On 6GB there is room for a couple of MB of drivers. Specially something that everybody has, like a screen.

> > Floppy? Which live CD still boots from floppy? They all moved to IDE
> > emulation years ago (IIRC Slackware 8.1 is the last major linux distro
> with
> > 2.88MB floppy emulation.
>
> I think there are still some (maybe obscure) single 1.44 or 2.88 floppu
> mini distros.

Probably if you search long and hard you will find obscure people running SCO and IRix of 9" discs. But I don't care about that either

> > (also for my non-dos purposes a more fully featured VESA would be a good
> > thing), but that is simply the way it is.
>
> Hm here you say that you would find usefull "more fully featured VESA" but
> from your previous write I got feeling that you want to kill ALL the legacy
> stuff, little bit inconsistent.

I was saying that nobody really expects VESA implementations to become better, only less, based on the current use that is used for. Namely to provide a minimal base for GUI during installation of an OS (be it Windows or *nix).

> Of course I understand there's now
> difference between my wishes and reality and I cannot do much more with it
> (except supportinig some obscure openHW/openFW projects).

There are multiple possibilities. Selecting hardware that actually works, participating in FreeDos, Coreboot. Anything but passively pining away on some forum bitterly complaining how everybody left poor old Dos alone, and that the programs that you still have are so perfectly good, and decide to wing it another year. But the end is inevitable, unless the remaining Dos users actively carve out a livable niche.

> > No problem, but the point I was trying to make is that the C=64/Amiga
> > community doesn't expect current vendors to tailor to their wishes. It
> is
> > the desire and illusion to run old software on new hardware ad infinitum
> > that causes the (self inflicted) pain.
>
> But C64/Amiga never aspired to became wide and long computer standard as
> PC.

I think both held out longer in their original formfactor than the PC did. So did the cards/expansion busses.

> The PC compatible was set this standard and now it's leaving it.

It has regularly changed. PC-XT-286-AT were not entirely compatible either, and later 386 extensions appeared, with Dos5.

> So I think it's time for raneming the whole architecture...

I don't see why. It is still the current incarnation of this architecture. That Dos stopped the evolving with it and clings to standards that are slowly being phased out, is not the problem of the architecture.

> Yes maybe it would was better that MSDOS was forgotten when 386 was
> introduced (before I got PC) and e.g. OS/2 was spreaded instead it.

I never said that. But Dos did nothing. It didn't go away, and didn't evolve anymore. It's that uncertainty why there probably never grew communities like even OS/2, Amiga, C=64 etc. And then I'm not even talking about the multi-billion Linux racket.

Win9x has the same problem. Once the most popular platform on the planet, nobody seems to mourn its demise. I haven't seen any usergroups springing up that actively keep win9x alive.

It's strange that I have to hear dos news on Unix conventions (some mentions about improved freedos support in a Coreboot session). It seems that nothing much happened on the Freedos site after januari-march 2010 (except the news posts about new packages)

> We
> would bring us much brighter future. But it didn't happened so and there
> spreaded a lot of DOS apps that I like. Maybe as you said the sharp break
> would be bettes. Even intel probably planned it with itanium IA64 which
> missing x86 (or poorly emulated) but it didn't become standard.

I think the main failure of EPIC/IA64 was that, like RISC it simplified CPU parts (RISC: decoding, EPIC: scheduling) that were becoming increasingly dwarfed in size by evergrowing caches.

It never even reached a budget workstation price, it stayed in the realm of extremely expensive servers.

> > The linux community builds own ARM and MIPS hardware and phones.
>
> I know. I was also thinking about something like that, make openHW PC
> (probably FPGA based) supporting all good standards of DOS day.

I don't know. Maybe you could base it on low power industrial x86 CPUs, that generally have a long life. Not cheap, but heavy duty FPGA's are probably more expensive.

> But as my
> student time has ended I will never have enough time to realize it. Maybe
> some chinese guys will come with such portable emulating DOS games/demos
> engine :)

And so the Dos community waits for a saviour. Again

> I would not have mentioned the following in a DOS forum, but you kinda
> started me... For CPU bound apps, NTVDM indeed is awfully slow -
> independent of display mode.

I've never noticed any slowdown for reasonable apps, but so many things can come into play (e.g. cpu, e.g. redir -t befi.com on AMD64x2 Vista was 5x slower than without redir). It just depends, but for most normal uses, it's the same speed (for me, in my obviously limited experience). By design it's not supposed to be much slower at all, so if it is, something went wrong.

NTVDM is deprecated and they won't fix (almost?) any bugs in it, at least that's the impression I get (slightly more than an educated guess). So it wouldn't surprise me if it did fail in some way, but overall it "mostly" works (at least XP, maybe not higher). It's far from perfect but indeed sad that it's dead. It runs what even DOSEMU can't, sometimes.

> Under the virtual DOS box of Windows 9x, the slowdown if much less than NT,
> but still significant (unbearable for the lengthy calculations). Except of
> course unlike NT you /could/ CLI under 9x ;=)
>
> One more reason to keep our DOS living !

Just for the record, pre-emptive multitasking has always been more expensive than cooperative or none. And yes NT has a higher runtime footprint than 9x. Win95 could run in 4 MB, NT always needed at least 16 MB (I think??). And yes, DOS being ultra minimal (with no tasks or drivers or TSRs) means it's sometimes (but not always) better for benchmarking or doing intense calculations. paq8o8z ran equally as fast under NTVDM in my tests, but HX + Oxford OBC output + MSVCRT ran quite a bit faster under DOS than Windows. So it varies. (And I still don't know what happened with LZMA-FPC under NTVDM, never bothered testing further since nobody cared.)

NT was never meant for home users, and they dragged their feet forever before finally switching to it (more stable). We all (should) know that older NT versions really sucked re: DOS support. Well, compared to today, they lacked a lot in other areas too. Win2k/XP tried adding and fixing a few things, and while it could (and should) have been much better, it was still okay. I don't expect them to work miracles, it's just maddening when they won't fix simple things or even pretend to care. And before marcov says, "Why should they?", let me say: 1). there's more legacy than new stuff, 2). it doesn't hurt them at all, it's a benefit, 3). they (should) know DOS better than anyone, 4). an OS that runs less stuff is not more valuable (duh?), 5). why not? 90,000 employees all too busy? (doubt it)

> And before marcov says, "Why should they?",

Why should they?


> 1). there's more legacy than new stuff,

But it is less used.

> 2). it doesn't hurt them at all, it's a benefit,

If you must retarget employees that could also do profitable things it does hurt. And the benefit is for less than an handful minimalists that apparantly never buy anything new from Microsoft

> 3). they (should) know DOS better than anyone,

Please. The people that worked at MS in the early days all became millionair on stockoptions and retired before 2000. For Vista/W7 they basically reverse engineered parts of their own kernel (search for "the big cycle" on the web)

> 4). an OS that runs less stuff is not more valuable (duh?),

Try it. Maybe if you guarantee a few million licenses sold, they'll probably listen. It could be that they happily fix your bugs if you make them an offer they can't refuse


> 5). why not? 90,000 employees all too busy? (doubt it)

They are doing profitable stuff, and catching up to android

> Well, turns out there is no real hurry, since while the integrated GPU is
> praised in all publications, it is still 5+ times slower than the cheapest
> ati or nvidia card, and we are not terribly pricesensitive there.

Really? I read that this GPU should compete with low level external VGA but didn't tested. But I prefer VGAs from nvidia bevause quite good drivers compared to intel where I had some problems before.

> Another big advantage of 64-bit is that the minimal CPU gets lifted to
> something Pentium-D like. This simplifies compilers considerably. copro is
> always integrated, ppro instructions (cmov) are, and SSE2 is always there
> (and SSE3 too if you are not too strict)

Understand. But it's similar effect when you write in specification that application's minimum system req. is P4D-x64 or e.g. PIII x86. It depends on you how much older CPU you want support.

> For me it usually worked. My fairly new ATI 5770 worked fine with 4xxx
> drivers.

Hm, seems ATI is more compatible around it's architecture, you had a luck but it's not general rule.

> I haven't seen mini disks for sale in ages, and when I did they were more
> expensive than white label DVDs. On 6GB there is room for a couple of MB
> of drivers. Specially something that everybody has, like a screen.

Here they are still available and cheap.
http://www.alza.cz/SearchAdvanced.asp?EXPS=cd-r+8cm
You can burn e.g. Tinycore or DSL on it.

> I was saying that nobody really expects VESA implementations to become
> better, only less, based on the current use that is used for. Namely to
> provide a minimal base for GUI during installation of an OS (be it Windows
> or *nix).

From this:
>> can use EFI for loading but who will rewrite DOS? This is
>> what I call end of IBM PC compatible.

>Thank god!


I interpreted that you are pleasured about kill all legacy inluding VESA, BIOS, etc.

> There are multiple possibilities. Selecting hardware that actually works,
> participating in FreeDos, Coreboot. Anything but passively pining away on
> some forum bitterly complaining how everybody left poor old Dos alone, and
> that the programs that you still have are so perfectly good, and decide to
> wing it another year. But the end is inevitable, unless the remaining Dos
> users actively carve out a livable niche.

I already do. Not directly on FD kernel (except one my small patch) i rather do some low-level utils interacting hardware. My tools are freely available at
http://rayer.ic.cz/programm/programe.htm
Some of them like MTRRLFBE can gain performance x-times. But need update for new core i*.
And I brought FreeDOS inside ROMBIOS
http://rayer.ic.cz/romos/romose.htm
As DOS still works on my current PC I didn't have forced into kernel work.
But there are people who did much more for DOS, my respect goes to Japheth, Jack Ellis and others...

> I don't see why. It is still the current incarnation of this architecture.
> That Dos stopped the evolving with it and clings to standards that are
> slowly being phased out, is not the problem of the architecture.

When BIOS will be dropped and replaced by EFI without comsaptability module it will affect not ONLY DOS but also all Windows up to XP, maybe Vista but they use same/similar loader like win7 which supports it.

> I never said that. But Dos did nothing. It didn't go away, and didn't
> evolve anymore. It's that uncertainty why there probably never grew
> communities like even OS/2, Amiga, C=64 etc. And then I'm not even talking
> about the multi-billion Linux racket.

It was just my speculation where we would be when DOS was ended long time and instead PC use OS/2 (or another advanced OS).

> Win9x has the same problem. Once the most popular platform on the planet,
> nobody seems to mourn its demise. I haven't seen any usergroups springing
> up that actively keep win9x alive.

You're blind. There's live commuity on MSFN around Win98SE who e.g. backported USB 2.0 drivers from XP and even developing kernel NTAPI extension (kernelex) and also generic VESA driver was developed for those who are out of luck with too modern VGA absenting drives. I also did some minor fixes to INF files for support newer chipsets and succesfully make RAM limit solution for systems with >1G RAM to not crash (even there's better solution supporting up to near 4G but commercial).

> It's strange that I have to hear dos news on Unix conventions (some
> mentions about improved freedos support in a Coreboot session). It seems
> that nothing much happened on the Freedos site after januari-march 2010
> (except the news posts about new packages)

True, but I'm not FD kernel developer to tell more about it.

> I don't know. Maybe you could base it on low power industrial x86 CPUs,
> that generally have a long life. Not cheap, but heavy duty FPGA's are
> probably more expensive.

The problem of most industrial boards are that don't support SB compatible soundcard or it is some poor crap. Also BIOS on such board may have more incompatabilities...

> And so the Dos community waits for a saviour. Again

Hm, we both have full time job (I expect you too) so it's not so easy to put enough effort and time as I want. And you will agree that making such complex HW design is not a piece of cake (like for 8-bit computers). Manufacturing and prototyping is expansive here much more than in china where is cheaper work and there are a lot of people that can spend some time on it.

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

> > Well, turns out there is no real hurry, since while the integrated GPU
> is
> > praised in all publications, it is still 5+ times slower than the
> cheapest
> > ati or nvidia card, and we are not terribly pricesensitive there.
>
> Really? I read that this GPU should compete with low level external VGA but
> didn't tested. But I prefer VGAs from nvidia bevause quite good drivers
> compared to intel where I had some problems before.

We do a lot of layered 2D work, and uploading is RDS. YMMV if you put more worth on shader performance.

> > Another big advantage of 64-bit is that the minimal CPU gets lifted to
> > something Pentium-D like. This simplifies compilers considerably. copro
> is
> > always integrated, ppro instructions (cmov) are, and SSE2 is always
> there
> > (and SSE3 too if you are not too strict)
>
> Understand. But it's similar effect when you write in specification that
> application's minimum system req. is P4D-x64 or e.g. PIII x86. It depends
> on you how much older CPU you want support.

True, but in the 64-bit case you don't get umpteen mails from all kinds of freaks that say they still have a type X-1 in some god forgotten corner (and of course they don't even explicitely say they actually want to run the software on the device, just that they "have" it)

> > For me it usually worked. My fairly new ATI 5770 worked fine with 4xxx
> > drivers.
>
> Hm, seems ATI is more compatible around it's architecture, you had a luck
> but it's not general rule.

Rule of thumb, if a new directx model that radically changes stuff is adopted, then you have to watch out. But there is only one such transition in recent time, DirectX9->10 which is indeed between Nvidia 7x and 8xxx

> > I haven't seen mini disks for sale in ages, and when I did they were
> more
> > expensive than white label DVDs. On 6GB there is room for a couple of
> MB
> > of drivers. Specially something that everybody has, like a screen.
>
> Here they are still available and cheap.
> http://www.alza.cz/SearchAdvanced.asp?EXPS=cd-r+8cm
> You can burn e.g. Tinycore or DSL on it.

Better use a stick and kill the moving parts. 2GB stick is Eur 5.

> From this:
> >> can use EFI for loading but who will rewrite DOS? This is
> >> what I call end of IBM PC compatible.
>
> >Thank god!
>
>
> I interpreted that you are pleasured about kill all legacy inluding VESA,
> BIOS, etc.

Well, I'm a bit allergic to self-declared standards. Or standards that people interpret their own way. You might occasionally get a catty response that way.

> > I don't see why. It is still the current incarnation of this
> architecture.
> > That Dos stopped the evolving with it and clings to standards that are
> > slowly being phased out, is not the problem of the architecture.
>
> When BIOS will be dropped and replaced by EFI without comsaptability module
> it will affect not ONLY DOS but also all Windows up to XP, maybe Vista but
> they use same/similar loader like win7 which supports it.

Afaik 64-bit win Vista and win 7 support EFI, and 32-bit not. But here, nearly everything new is delivered with a 64-bit OS.

It can take another couple of years, or they can start switching to EFI in fall, nobody knows. Still a transition will take some time, so probably we are good for at least 2 years.

(at home I want 64-bit, at work we are dependant on certain 32-bit drivers and a 32-bit only compiler (damn you Borland/Embarcadero!))

> > Win9x has the same problem. Once the most popular platform on the
> planet,
> > nobody seems to mourn its demise. I haven't seen any usergroups
> springing
> > up that actively keep win9x alive.
>
> You're blind. There's live commuity on MSFN around Win98SE who e.g.
> backported USB 2.0 drivers from XP and even developing kernel NTAPI
> extension (kernelex) and also generic VESA driver was developed for those
> who are out of luck with too modern VGA absenting drives. I also did some
> minor fixes to INF files for support newer chipsets and succesfully make
> RAM limit solution for systems with >1G RAM to not crash (even there's
> better solution supporting up to near 4G but commercial).

Ok, I stand corrected then.

> > I don't know. Maybe you could base it on low power industrial x86 CPUs,
> > that generally have a long life. Not cheap, but heavy duty FPGA's are
> > probably more expensive.
>
> The problem of most industrial boards are that don't support SB compatible
> soundcard or it is some poor crap. Also BIOS on such board may have more
> incompatabilities...

Better than creating an own bios from start?

> > And so the Dos community waits for a saviour. Again
>
> Hm, we both have full time job (I expect you too) so it's not so easy to
> put enough effort and time as I want. And you will agree that making such
> complex HW design is not a piece of cake (like for 8-bit computers).

The heavy Amiga's were more complex than early PCs. They are more or less 386s.

> Manufacturing and prototyping is expansive here much more than in china
> where is cheaper work and there are a lot of people that can spend some
> time on it.

That is only cheaper when you go to extreme volumes. And there is no reason why you can't order your prints in China. I know we did for a while.

> True, but in the 64-bit case you don't get umpteen mails from all kinds of
> freaks that say they still have a type X-1 in some god forgotten corner
> (and of course they don't even explicitely say they actually want to run
> the software on the device, just that they "have" it)

Yes it's very comfortable from programmer's view but disliked from user view. Like putting a gun to head and say buy better HW or die. In extreme case user will got 0% performance gain, 2x memory consumption just because someone decided to use 64bit compiler even if it wouldn't use any new instruction.

> You might occasionally get a catty response that way.

Yes I sometimes got them. But didn't expected it on DOS forum.

> (at home I want 64-bit, at work we are dependant on certain 32-bit drivers
> and a 32-bit only compiler (damn you Borland/Embarcadero!))

I also have to downgrade new machine at work to 32bit bacause of Orcad and Altium. So I have unused 4GB of memory there but don't care a lot because 32bit XP are less memory hungry (and used apps too) :). But it was decision of our IT that we need it :)

> Better than creating an own bios from start?

It depends... On 3rd party HW I don't have any docs, schematics, sources so it's hard to fix. If I would start my design I will know about all GPIO connections etc. and then can modify e.g. coreboot + seabios to fit.

> > complex HW design is not a piece of cake (like for 8-bit computers).
>
> The heavy Amiga's were more complex than early PCs. They are more or less
> 386s.

I was talking about 8-bit computers and Amiga was AFAIK based od 32-bit motorola 68000 later 68030,40,60... So it may be comparable to 486 PC.

> That is only cheaper when you go to extreme volumes. And there is no reason
> why you can't order your prints in China. I know we did for a while.

Yes we also do. But for a single prototype it doesn't have any advantage. But if someone in china will take it seriously and create something like dingoo gaming console it will be cheap. And I belive that DOS is more popular in china (China DOS Union, but because of language barrier we don't hear about them much often) than here so maybe someone will realize it :) For me as a single person it will take years using free time.

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

>> ... For CPU bound apps, NTVDM indeed is awfully slow -
>> independent of display mode.
>
> I've never noticed any slowdown for reasonable apps, but so many things can
> come into play (e.g. cpu, e.g. redir -t befi.com on AMD64x2 Vista was 5x
> slower than without redir). It just depends, but for most normal uses, it's
> the same speed (for me, in my obviously limited experience). By design it's
> not supposed to be much slower at all, so if it is, something went wrong.

Admittedly the pure computing case is rare, and my calculations are extreme - in that they try very hard to run entirely in CPU and mostly in general integer registers; I went to great lengths to avoid hitting memory and even the caches - for instance, when I need to keep a "carry" around a couple instructions, it won't pushf/popf but had rather setc reg8/neg reg8 or even our old pair of friends, lahf/sahf ;=) In such conditions, any context switch is catastrophic, clearly. I wouldn't use Windows or any multitasking OS to run the task seriously, but for tuning my progs and quickly testing the mods of course Windows is convenient and even comfortable.

[More DOS-topical : I never found a good DOS task switcher but for Windows itself. All DOS task switchers that I tried back then... were buggy or deficient or both. IIRC that included taskers from Norton, Central Point (when they had not yet become parts of the same entity), DRDOS's "tasmax", and more. The only half acceptable thing came later, viz the task switcher included by MS with DOS 5 (?) and DOS 6.0 (retired from 6.2 iirc). But of course the latter was a stripped down version or at least derived from the Windows 3.x (real or 'standard' mode) DOSSWAP and was OK. Now I'm not often finding myself praising something from Microshaft...]

Win 2k again : that question about controlling the time quantum - both globally AND per task (process, or thread maybe) is still open, if anyone lurking here has knowledge of hidden parameters (maybe from studying the so-called Research Kernel ?) I'll love to hear from them...

Regards

---
Ninho

> [More DOS-topical : I never found a good DOS task switcher but for
> Windows itself. All DOS task switchers that I tried back then... were buggy
> or deficient or both. IIRC that included taskers from Norton, Central Point
> (when they had not yet become parts of the same entity), DRDOS's "tasmax",
> and more.

Desqview? But that's impossible to legally find nowadays. And BTW, wasn't TASKMAX old from DR-DOS 6? Novell DOS 7 / Caldera DR-DOS 7.03 has real pre-emptive multitasking (though requires its vaguely buggy EMM386) with TASKMGR, if you have a 386 (else task switching for 286). Not everything works, of course, but it's okay. In particular, 7.03 (and 7.02?) are closed source (natch), but at least their DPMI host (needed for multitasking) is much better, e.g. DJGPP and 32-bit friendly (finally).

RDOS claims to be GPL/non-commercial, and it supposedly multitasks and has a DPMI server and can even allegedly be built (now) with OpenWatcom. But I've never seen any mention of a recent binary (only raw disk image from a few years ago which I was apparently too dumb to figure out how to boot.) So you could try that (in theory) ....

> The only half acceptable thing came later, viz the task switcher
> included by MS with DOS 5 (?) and DOS 6.0 (retired from 6.2 iirc).

I assume you mean DOSSHELL, which appeared circa DOS 4. It only did task swapping, e.g. only one app at a time but saved the other in conv. mem. It wasn't discontinued (I think?) but was still definitely available in supplemental pack (DOSSUPL?). But yes, clearly they did want everyone to also buy Windows (esp. since they exclusively bundled DOS + Win = Win95).

> But of
> course the latter was a stripped down version or at least derived from the
> Windows 3.x (real or 'standard' mode) DOSSWAP and was OK. Now I'm not often
> finding myself praising something from Microshaft...]

I think Win 3.1 was better than DOSSHELL, but I haven't tested it lately to say for sure. At the very least, it allowed more than just conv. mem.

> Win 2k again : that question about controlling the time quantum - both
> globally AND per task (process, or thread maybe) is still open, if anyone
> lurking here has knowledge of hidden parameters (maybe from studying the
> so-called Research Kernel ?) I'll love to hear from them...

NT loses lots of ticks doing God knows what, and it doesn't always do the smartest thing. Worse is when antivirus or file indexing is running (or even Windows update), which slows everything to a crawl. It's much more obvious on single core PCs and/or with less than ideal amounts of RAM. It's clear that most people don't test very well across a wide variety of hardware. NT must be a bear to maintain because clearly they haven't organized everything (ahem, registry hack for DPMI limit? really?? 100% undocumented too, even better). That and the hardcoded filename flags for UAC really seemed inelegant to me. Oh well, nobody's perfect.

> [More DOS-topical : I never found a good DOS task switcher but for
> Windows itself. All DOS task switchers that I tried back then... were buggy

From what I had tried the best perfomr DR-DOS task manager. E.g. I maneged to run 2x Quake, DN, and something else and switch between. Taks run on backgroud. You can adjust time slices for foreground/background tasks. But it's binded to drdos emm386.exe which has some compatability issues/bugs. I don't know how havily it depends. Maybe Japheth could add some missing fuction but as we don't know what and what it do. If you want to try it here's the complete drdos:

EDIT: http://www.drdos.com/products/drdos703.htm "Single User, $35.00, Buy Now"

> EDIT: http://www.drdos.com/products/drdos703.htm "Single User, $35.00,
> Buy Now"

Sorry about that, better safe than sorry.

(BTW, rr, was it intentional or not to leave me as moderator? IIRC, you went out of town quite a while ago, and even I mostly forgot well after that, but I never was courageous enough to ever bother with anything. Well, I've seen you do similar corrections here on rare occasion, so I hope I didn't overstep my bounds. But either way is no sweat off my back.)

> From what I had tried the best perfomr DR-DOS task manager. E.g. I maneged
> to run 2x Quake, DN, and something else and switch between. Taks run
> on backgroud. You can adjust time slices for foreground/background
> tasks. But it's binded to drdos emm386.exe which has some
> compatability issues/bugs.

It has some weird keyboard issues when loaded, moreso if DPMI is "off". I've even had some apps hang with it, perhaps even Mpxplay and NDN (can't remember). Also, don't forget, hard limited to 64 MB per task, which can be somewhat annoying in modern times (and that's whether you use a separate XMSv3 or not). Maybe most of us don't care (I don't majorly), but it's still a limit to be wary of. GCC optimizations can easily eat up that much (and multitasking while compiling is definitely more pleasant than waiting for the dumb thing to finish, too slow!!).

> I don't know how havily it depends.

Pretty heavily, and actually I think it's documented somewhere that EMM386.EXE has several binaries/drivers embedded in itself (oddly enough), possibly even old code from MS and Quarterdeck (presumably legal, heh).

> Maybe Japheth could add some missing fuction but as we don't know
> what and what it do. If you want to try it here's the complete drdos:

I don't think Japheth can work miracles. Well, he's definitely a DOS saint, but still .... No, seriously, it's too weird and closed source. Even OpenDOS never released it, honestly probably because they don't have the licenses from various people to do so. (As mentioned, EMM386 uses some weird proprietary code.)

> > [More DOS-topical : I never found a good DOS task switcher but
> for
> > Windows itself. All DOS task switchers that I tried back then... were
> buggy
> > or deficient or both. IIRC that included taskers from Norton, Central
> Point
> > (when they had not yet become parts of the same entity), DRDOS's
> "tasmax",
> > and more.
>
> Desqview?

I've been co-sysop at a Desqview(later /X) BBS and Fido hub for years. Very stable, and fairly fast. DVX - SBBS (later RA) FrontDoor - FMail was a fairly common combination in those days.

From what I remember from it, the memory allocation was not as good as a real OS, memory was assigned to dosboxes on startup, and not demand-allocated. Setting lower memory limits on dosboxes helped with that (since all these systems were by definition memory-starved)

The BBS moved to NT4 later, when 32MB became affordable. (DV ran in 4 or 8MB, /X could run in 8, but prefered more, iirc the longest running config had a DX2/66 with 16MB.) The main reason for the move to NT4 was better and more reliable ethernet support, and still better multitasking.

NT4 felt sluggish as a desktop, but when everything was started, it was fairly bearable. (and e.g. the binary memory mapping architecture of Windows clearly helped here, since some apps had only a very small memory footprint during the day, but only required more memory and a large part of the binary in midnight events)

> > True, but in the 64-bit case you don't get umpteen mails from all kinds
> of
> > freaks that say they still have a type X-1 in some god forgotten corner
> > (and of course they don't even explicitely say they actually want to
> run
> > the software on the device, just that they "have" it)
>
> Yes it's very comfortable from programmer's view but disliked from user
> view.

No. There are advantages for the user too, since he gets optimized binaries.

> Like putting a gun to head and say buy better HW or die.

Of course not. One can use old software ad infinitum.

> In extreme
> case user will got 0% performance gain, 2x memory consumption just because
> someone decided to use 64bit compiler even if it wouldn't use any new
> instruction.

Yes, and in other extreme cases it is twice as fast (as e.g. AES encryption). So what?

> > You might occasionally get a catty response that way.
>
> Yes I sometimes got them. But didn't expected it on DOS forum.

IMHO there are no taboos here.

> > (at home I want 64-bit, at work we are dependant on certain 32-bit
> drivers
> > and a 32-bit only compiler (damn you Borland/Embarcadero!))
>
> I also have to downgrade new machine at work to 32bit bacause of Orcad and
> Altium. So I have unused 4GB of memory there but don't care a lot because
> 32bit XP are less memory hungry (and used apps too) :). But it was decision
> of our IT that we need it :)

Well, I could run the 32bit app under windows 64bit if it were not for certain hardware drivers. But one of the crucial vendors has said he will publish 64-bit drivers this year, and the question will be if his 32-bit userland lib can interface 64-bit drivers. That would yield a nearly full 32-bit application space.

> > Better than creating an own bios from start?
>
> It depends... On 3rd party HW I don't have any docs, schematics, sources so
> it's hard to fix. If I would start my design I will know about all GPIO
> connections etc. and then can modify e.g. coreboot + seabios to fit.

If you really must emulate legacy busses like ISA like they were native it will be hard. From what I got from the Coreboot guys, the current super I/O chips are quite complex.

> > > complex HW design is not a piece of cake (like for 8-bit computers).
> >
> > The heavy Amiga's were more complex than early PCs. They are more or
> less
> > 386s.
>
> I was talking about 8-bit computers and Amiga was AFAIK based od 32-bit
> motorola 68000 later 68030,40,60... So it may be comparable to 486 PC.

40 is halfway between 486 and pentium. It is a DX/DX2 hybrid (some parts run on double speed, some not), and has a simple pipelining.

Multiple pipes multiple instructions per clock. 60 afaik is halfway between pentium and ppro (in philosophy, not in performance. It is a low clocked pentium in performance, and more)

> > That is only cheaper when you go to extreme volumes. And there is no
> reason
> > why you can't order your prints in China. I know we did for a while.
>
> Yes we also do. But for a single prototype it doesn't have any advantage.

IIRC while lower counts are possible, anything below 10 prints is nearly as expensive as 10 prints. And even with 10 prints the costs are significantly more than 25. We usually do 10 for "first" prints and 25 otherwise (since usually the basic parts will work, and only "new" functionality is at risk)

We have 4 layer SMD 100 pin device prints, but that is still several magnitudes less complex than a mainboard.

> But if someone in china will take it seriously and create something like
> dingoo gaming console it will be cheap. And I belive that DOS is more
> popular in china (China DOS Union, but because of language barrier we don't
> hear about them much often) than here so maybe someone will realize it :)

Popular and "used" are two different things. And I'm afraid it is the latter rather than the former.

As said, people only using their own old stuff don't contribute much to such efforts. The number of people still investing in Dos, that is the figure you are looking for as a base for such operations.

> > EDIT: http://www.drdos.com/products/drdos703.htm "Single User,
> $35.00,
> > Buy Now"
>
> Sorry about that, better safe than sorry.

Hey, I downloaded this disks from Lineo official site before many years when it was freely available so I have it perfectly legal. I didn't know that they mfkrs started to selling it now for such (high) price...

> Pretty heavily, and actually I think it's documented somewhere that
> EMM386.EXE has several binaries/drivers embedded in itself (oddly enough),
> possibly even old code from MS and Quarterdeck (presumably legal, heh).

Aha, then forget it...

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

> Of course not. One can use old software ad infinitum.

But you can change application data format to be incompatible with previous version this will isolate the user with old SW and after some time he will be forced to buy new SW+HW. Microsoft can teach us :)

> Yes, and in other extreme cases it is twice as fast (as e.g. AES
> encryption). So what?

2x fast only due to 64bit if used same MMX/SSE insctructions both on 32bit and 64bit CPU?

> IMHO there are no taboos here.

Of course not. But I also don't go to linux forum and tell them that e.g. linux on desktop is a nonsense because Windows have more intuitive GUI and generaly rules on 99% desktops...

> Multiple pipes multiple instructions per clock. 60 afaik is halfway
> between pentium and ppro (in philosophy, not in performance. It is a low
> clocked pentium in performance, and more)

I didn't want to compare their performance just point that 8-bit HW (C64, ZX...) are much easier than PC. Also the strictly HW standard of these computers is big advantege for programing kernel and drivers. PC is generic glued from many different parts so it's not such easy...

> IIRC while lower counts are possible, anything below 10 prints is nearly as
> expensive as 10 prints. And even with 10 prints the costs are significantly
> more than 25. We usually do 10 for "first" prints and 25 otherwise (since
> usually the basic parts will work, and only "new" functionality is at
> risk)

Yes. We do usually 4 for prototypes and send it to local PCB manufacturer simply because he is fast. If I send it to china I will see my board after ~3 weeks. We send there thousand batches.

> We have 4 layer SMD 100 pin device prints, but that is still several
> magnitudes less complex than a mainboard.

I personally did only 6-layer with TQFP144 (0.4mm pitch) CPU and BGA 121 GSM module, still much less than real mobo. But now we are started to use microvias (LASER drilled) that helps the design a lot...

> Popular and "used" are two different things. And I'm afraid it is the
> latter rather than the former.

I think they also develop something I'll have to take a google translator and browse their forum when have a time...

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

> > Of course not. One can use old software ad infinitum.
>
> But you can change application data format to be incompatible with previous
> version this will isolate the user with old SW and after some time he will
> be forced to buy new SW+HW.

Then change it to subscription based, so that a devel extra gets money for old versions, and see how many subscribe.

> Microsoft can teach us :)

The Microsoft situation was extreme because they could allow themselves things normal vendors couldn't, due to OEM situation and the fact that gigantic amounts of new users came to the market in the 1995-2002.

But the problem is general, not just Microsoft. Even if money is not a factor this happens. Because there are also other interests except money to push software forward.

> > Yes, and in other extreme cases it is twice as fast (as e.g. AES
> > encryption). So what?
>
> 2x fast only due to 64bit if used same MMX/SSE insctructions both on 32bit
> and 64bit CPU?

AES is a special case because it requires a fairly hefty 64-bit integer calculation. IIRC SSE has no 64-bit integer. Only the 64-bit ALU has. (well and the FPU has comp, bu not logic operations)

> > IMHO there are no taboos here.
>
> Of course not. But I also don't go to linux forum and tell them that e.g.
> linux on desktop is a nonsense because Windows have more intuitive GUI and
> generaly rules on 99% desktops...

If a related subject comes up I will. And if some parrot means to speak out the cliche "this is the year of the Linux desktop", I'll be the first to remember him of the fact that that is like the 10th or the 11th year in a row that was declared the year that Linux would make it onto the desktop.

> > Multiple pipes multiple instructions per clock. 60 afaik is halfway
> > between pentium and ppro (in philosophy, not in performance. It is a low
> > clocked pentium in performance, and more)
>
> I didn't want to compare their performance just point that 8-bit HW (C64,
> ZX...) are much easier than PC.

Well, you target one specific PC. And for PC high frequency silicon is already available, exempting you from the most difficult task. But the problem will also be which PC you exactly are going to emulate. For newergames you want high freq and fast graphics, while for old games you want a perfect timing emulation.

> Also the strictly HW standard of these
> computers is big advantege for programing kernel and drivers. PC is generic
> glued from many different parts so it's not such easy...

Well, but you have modern commercially available parts. SLightly older ones (and thus with better known spec) even in the industrial market.


> Yes. We do usually 4 for prototypes and send it to local PCB manufacturer
> simply because he is fast. If I send it to china I will see my board after
> ~3 weeks. We send there thousand batches.
>
> I personally did only 6-layer with TQFP144 (0.4mm pitch) CPU and BGA 121
> GSM module, still much less than real mobo. But now we are started to use
> microvias (LASER drilled) that helps the design a lot...

We only do about 50 devices a year. It is an auxilery I/O and control board where the main parts are bought.

(combining replies here):

> I've been co-sysop at a Desqview(later /X) BBS and Fido hub for years.
> Very stable, and fairly fast. DVX - SBBS (later RA) FrontDoor - FMail
> was a fairly common combination in those days.

The Desqview/X SDK was written with DJGPPv1 (and is still on the mirrors). The problem with a lot of DOS software is that it disappeared (abandoned, deleted, no longer sold), not (only) that it was commercial and had weird licenses.

Also, it really is hard to rewrite everything from scratch. I guess I don't have to tell you (BSD fan). Worse is when it's undocumented, which makes things almost impossible. At least FreeDOS (free/libre) "mostly" does everything we need, which is no small feat given all the efforts that went into it.

> Hey, I downloaded this disks from Lineo official site before many years
> when it was freely available so I have it perfectly legal. I didn't know
> that they mfkrs started to selling it now for such (high) price...

$35 is far from a high price for any software. And it's been that way for quite a while. I bought my copy online in 2004 for the same price. But Novell DOS 7 (buggier DPMI) was like $125 in 1994. I think even PC-DOS 7 was similarly priced (and I even saw that on eBay recently for like $50). So, relatively speaking, it's a bargain (assuming it works for your needs, of course).

Ownership has changed hands a few times, and obviously the license too. OpenDOS wasn't "open" except very very barely (non-commercial for you but they can use your changes), and even that was only (I think?) kernel and shell, not auxiliary tools. Even that one wasn't with all the Novell fixes due to version control issues. With 7.02/7.03, it went back closed source, but at least they did make some improvements (e.g. less buggy DPMI, now DJGPP friendly). They (Caldera?) allegedly used the income to fund their Linux businesses, oddly enough. But Caldera / Lineo doesn't even exist anymore (does it?). It then went to DeviceLogics and then spun off DR-DOS, Inc. Yeah, I've read rumors about DR-DOS being free for non-commercial use, but I'm not sure that was ever true (or else they changed their minds later). I think it was "commercially try for 90 days or reasonable period for home use", but I dunno anymore. At least as of 2004, "Caldera DR-DOS 7.03 = $35 for single user at home", and their website still says similar, so I guess nothing's changed.

> 2x fast only due to 64bit if used same MMX/SSE insctructions both on
> 32bit and 64bit CPU?

64-bit is not faster. Not at all. Only in very rare cases. It really is almost a waste to pretend otherwise. None of us home users need 64-bit unless we're doing something weird (which we never needed to do in the past 20 years) using huge amounts of RAM. It's easy to say nobody needs it because nobody used to have it!! How can you "need" what you don't have?

Why did they not implement V86 under long mode? Dunno, probably because commercially MS and Linux don't need (nor want) it, not in the slightest. Or maybe there was some unknown (to us) technical limit like only a certain amount of transistors could fit on limited die space (extremely blind guess, I'm no hardware engineer). Or maybe they were lazy, who knows.

Win8 (two years away) will probably be 64-bit only, even for home users. Okay, that's kinda lame, but it's not that surprising or the end of the world. Even though I like DOS, I don't reasonably expect anybody else to. My issue is that it's a slippery slope, and I don't ever (!) want them to remove 32-bit compatibility. It's very easy to imagine them forcing us to make all our binaries PE64, which would be very very short-sighted, IMNSHO.

> I didn't want to compare their performance just point that 8-bit HW
> (C64, ZX...) are much easier than PC. Also the strictly HW standard of
> these computers is big advantege for programing kernel and drivers. PC
> is generic glued from many different parts so it's not such easy...

Yes, modern PCs are crap. It's great that they're cheap and powerful, but they're too complicated, somewhat horrible licensing (and patents), too many incompatible APIs, binary formats, OSes, etc., and honestly we've even lost functionality because of incompatible hardware. It's a far cry from the 486/586 days when everything was "easy". It's not that I want us to go back or lose "modern" functionality (eh?), but it was indeed a simpler and better time in some ways, no worries about all these complicated, broken modern things that (almost) nobody needs.

> > [More DOS-topical : I never found a good DOS task switcher but
> for
> > Windows itself. All DOS task switchers that I tried back then... were
> buggy
> > or deficient or both. IIRC that included taskers from Norton, Central
> Point
> > (when they had not yet become parts of the same entity), DRDOS's
> "tasmax",
> > and more.
>
> Desqview? But that's impossible to legally find nowadays. And BTW, wasn't
> TASKMAX old from DR-DOS 6? Novell DOS 7 / Caldera DR-DOS 7.03 has real
> pre-emptive multitasking (though requires its vaguely buggy EMM386) with
> TASKMGR, if you have a 386 (else task switching for 286). Not everything
> works, of course, but it's okay. In particular, 7.03 (and 7.02?) are closed
> source (natch), but at least their DPMI host (needed for multitasking) is
> much better, e.g. DJGPP and 32-bit friendly (finally).

Indeed I used to be a mostly happy DRDOS 6 user before Win 95 tricked us into switch back to MSDOS, well known story... Never used any of the DRDOS 7's, safe for a handful boot diskettes maybe. Sadly, I can't see myself going back from MSDOS 7.10 to DRDOS (or any other 16 bit DOS) nowadays, even if it were free/libre/accessible. MS won the battle by all means, dirty tactics included, but that's history.


> RDOS claims to be
> GPL/non-commercial, and it supposedly multitasks and has a DPMI server and
> can even allegedly be built (now) with OpenWatcom. But I've never seen any
> mention of a recent binary (only raw disk image from a few years ago which
> I was apparently too dumb to figure out how to boot.) So you could try that
> (in theory) ....

Right, in theory, I could try :=)

>> The only half acceptable thing came later, viz the task switcher
>> included by MS with DOS 5 (?) and DOS 6.0 (retired from 6.2 iirc).

> I assume you mean DOSSHELL, which appeared circa DOS 4. It only did task
> swapping, e.g. only one app at a time but saved the other in conv. mem. It
> wasn't discontinued (I think?) but was still definitely available in
> supplemental pack (DOSSUPL?).

Yep that's it, the DOSSHELL, whose task swapper component was named DOSSWAP.EXE, iirc. Not bad at all on a 286 -IF- swapping to a RAMDisk (old 286 AT clone maxed with 8 Meg RAM! plus a 4 Meg EMS 3.0 board recovered from an even older XT. You wouldn't believe, that was swapping FAST !)

>But yes, clearly they did want everyone to
> also buy Windows (esp. since they exclusively bundled DOS + Win = Win95).

Aren't you happily skipping over Windows 3.0/3.1 ! Win 3 was crappy still, but 3.1 -standard mode- quite fine (and 3.11 WfW, which could be forced to run in standard mode too despite offical claims to the contrary) was really GOOD. In fact Windows 95 "gold" is little more than WfW 3.11 with more modern GUI, plus the "plug and play" thing that we all loved (or did we?)


>> But of course the latter was a stripped down version or at least derived from the Windows 3.x (real or 'standard' mode) DOSSWAP and was OK.

> I think Win 3.1 was better than DOSSHELL, but I haven't tested it lately to
> say for sure. At the very least, it allowed more than just conv. mem.

It was better indeed in that it swapped to extended mem instead of the DOSSHELL swapping to disk - but see my above remark about RAMdisks.


>> Win 2k again : that question about controlling the time quantum - both
>> globally AND per task (process, or thread maybe) is still open, if
> anyone
>> lurking here has knowledge of hidden parameters (maybe from studying the
>> so-called Research Kernel ?) I'll love to hear from them...

> NT loses lots of ticks doing God knows what, and it doesn't always do the
> smartest thing. Worse is when antivirus or file indexing is running (or
> even Windows update), which slows everything to a crawl. It's much more
> obvious on single core PCs and/or with less than ideal amounts of RAM. It's
> clear that most people don't test very well across a wide variety of
> hardware. NT must be a bear to maintain because clearly they haven't
> organized everything (ahem, registry hack for DPMI limit? really?? 100%
> undocumented too, even better). That and the hardcoded filename flags for
> UAC really seemed inelegant to me. Oh well, nobody's perfect.

As we all can testify. Well...

--
Ninho

>
> Also, it really is hard to rewrite everything from scratch. I guess I don't
> have to tell you (BSD fan). Worse is when it's undocumented, which makes
> things almost impossible. At least FreeDOS (free/libre) "mostly" does
> everything we need, which is no small feat given all the efforts that went
> into it.

Huh, how does it replace DV/X? Does it have job control or so?

> > 2x fast only due to 64bit if used same MMX/SSE insctructions both on
> > 32bit and 64bit CPU?
>
> 64-bit is not faster. Not at all. Only in very rare cases. It really is
> almost a waste to pretend otherwise. None of us home users need 64-bit
> unless we're doing something weird (which we never needed to do in the past
> 20 years) using huge amounts of RAM. It's easy to say nobody needs it
> because nobody used to have it!! How can you "need" what you don't have?

In my experience it about evens out on non-Windows. The larger datasegment size on one hand, and the large number of registers and raised minimal instruction level (and the systematic use of both in every library) about cancel eachother.

Crafted 32-bit code is probably faster, but on average code it cancels out.

> Why did they not implement V86 under long mode?

One emulation only. 64-bit has 32-bit. 32-bit has 16-bit.

> Dunno, probably because
> commercially MS and Linux don't need (nor want) it, not in the slightest.

That next to nobody needs it is probably true too.

> Or maybe there was some unknown (to us) technical limit like only a certain
> amount of transistors could fit on limited die space (extremely blind
> guess, I'm no hardware engineer). Or maybe they were lazy, who knows.

And more importantly, if they add it now for a few 16-bit vigilantes, they can't get rid of it till 2025. Keep in mind that 80386 was introduced in 1985, and as an arch is only starting to be phased out.

If you take 2003 as start of x86_64 that means if they had added 16-bit mode they probably had to lug it along till 2003+(2010-1985)=2028

> I don't ever (!) want them to
> remove 32-bit compatibility.

I'm not that afraid about 32-bit EXEs running, but 32-bit OSes are in danger due to the BIOS->EFI change.

> It's very easy to imagine them forcing
> us to make all our binaries PE64, which would be very very short-sighted,
> IMNSHO.

Naah. The wrath of the long tail rules there. PE bins will run for quite a while within windows. And I guess 32-bit OSes will run for a handful of years minimum too. Anyone who says that he can look forward longer than that must be a multi-millionaire, since he would have bought a gazillion Apple shares early this decennium if he could forsee IT that well.

> Yes, modern PCs are crap. It's great that they're cheap and powerful, but
> they're too complicated, somewhat horrible licensing (and patents), too
> many incompatible APIs, binary formats, OSes, etc., and honestly we've even
> lost functionality because of incompatible hardware. It's a far cry from
> the 486/586 days when everything was "easy". It's not that I want us to go
> back or lose "modern" functionality (eh?), but it was indeed a simpler and
> better time in some ways, no worries about all these complicated, broken
> modern things that (almost) nobody needs.

Sigh, more nagging and whining. What are you going to about it?

> > Also, it really is hard to rewrite everything from scratch. I guess I
> don't
> > have to tell you (BSD fan). Worse is when it's undocumented, which makes
> > things almost impossible. At least FreeDOS (free/libre) "mostly" does
> > everything we need, which is no small feat given all the efforts that
> went
> > into it.
>
> Huh, how does it replace DV/X? Does it have job control or so?

No (see "mostly"?), that was the point, you can't replace something when it's heavily undocumented (though Win16 is worse here).

> In my experience it about evens out on non-Windows. The larger datasegment
> size on one hand, and the large number of registers and raised minimal
> instruction level (and the systematic use of both in every library) about
> cancel eachother.

You don't need extra registers (use push/pop). You don't need to assume SSE2 (use CPUID), which most compilers can't target anyways. Besides, there are ten bazillion extensions since SSE2 was a standard on all PCs (P4 - 2000, AMD64 - 2003): SSE3, SSSE3, SSE4.[12], AVX, etc. (Even new cpus don't have all these, not even close!) Yes, in very rare cases, SSE2 can speed up an app significantly, but you don't need 64-bit for that.

> > Why did they not implement V86 under long mode?
>
> One emulation only. 64-bit has 32-bit. 32-bit has 16-bit.

16-bit covers real mode (8086 - MS-DOS) and pmode (286 - OS/2 1.x), two entirely different things (though they both use segmentation).

I've heard conflicting reports (Ross Ridge, Bart Oldemann), so I'm not entirely sure if the cpu (long mode) itself or just the 64-bit OSes (Win64, Linux64) refuse to support one or both of those.

> > Dunno, probably because
> > commercially MS and Linux don't need (nor want) it, not in the
> slightest.
>
> That next to nobody needs it is probably true too.

The cpu and OS vendors are heavily tied together and make decisions (sometimes irrational) based upon one another (silly examples redacted).

> And more importantly, if they add it now for a few 16-bit vigilantes, they
> can't get rid of it till 2025. Keep in mind that 80386 was introduced in
> 1985, and as an arch is only starting to be phased out.

The 286 was still used until early '90s (according to Wikipedia). So it's unfair to think that 100% (or even 50%) of all cpus in 1985 were 386s. Even if they were, software had to catch up. (CWS even has an old 386 laptop with only 512 kb of RAM! Yet Japheth's 486 now has 32 MB, heh. So it's a weird playing field.)

MS was still working with IBM on OS/2 1.x as late as 1991. Win 3.0 (1990) was the last to still support 8086. NT (386) didn't come out until 1993 and wasn't targeted at home users until XP (2001). (You could argue about Win95's Win32 or Win32s API here, but those were still DOS-based systems.) Even VCPI (386) and DPMI (286, 386) didn't appear until 1989/1990. DJGPP started on a real 386 (w/ 2 MB) in 1989. Linux started on a real 386 back in 1991. Don't forget that even BP7 (1992?) didn't support 32-bit (as you're obviously well aware!), nor did even Delphi 1 (1995).

> If you take 2003 as start of x86_64 that means if they had added 16-bit
> mode they probably had to lug it along till 2003+(2010-1985)=2028

No, because 2003 was when AMD64 Opteron servers first appeared (right?). When did they start targeting home users? How many had/have AMD64 cpus? How many use 64-bit OSes? Similar to Intel except home users never got Core 2 until 2006. So you should consider 2006 as the (full) "introduction" (cpu only). XP 64-bit was 2005 but most people didn't have that (again, not targeted at consumers). So Vista (2007) would be the (partial) "introduction" of Win64 to some home users. Until Win8 (two years away?), assuming rumors are correct about it being 64-bit only, you can't say the market is level. And that's only the beginning! You can't support what nobody has yet, the market is mostly old stuff (since that's completely reasonable). So you have to add a few more years. So it doesn't truly "begin" until then (2013) anyways. Then 32-bit will be declared dead, same as DOS was declared dead with XP.

> > I don't ever (!) want them to remove 32-bit compatibility.
>
> I'm not that afraid about 32-bit EXEs running, but 32-bit OSes are in
> danger due to the BIOS->EFI change.

All new drivers (sigh), another drawback.

> > It's very easy to imagine them forcing
> > us to make all our binaries PE64, which would be very very
> short-sighted,
> > IMNSHO.
>
> Naah. The wrath of the long tail rules there. PE bins will run for quite a
> while within windows. And I guess 32-bit OSes will run for a handful of
> years minimum too. Anyone who says that he can look forward longer than
> that must be a multi-millionaire, since he would have bought a gazillion
> Apple shares early this decennium if he could forsee IT that well.

Of course they can't do it now. But give them five years. As long as 50%
of the people "don't care", they'll probably do it. I mean, if they
can't even keep NTVDM barely working on XP (2001-6), what makes you
think WoW 32-bit will be any different??

> > Yes, modern PCs are crap.
>
> Sigh, more nagging and whining. What are you going to about it?

What do you reasonably expect me to do about it? Do you really think
Win32 or FreeBSD64 is the answer? Doubt it. And certainly you don't
expect me to roll my own hardware (though presumably the 386 is patent
free by now, maybe even 486, I dunno).

> NTVDM is deprecated and they won't fix (almost?) any bugs

COOL

> There's live commuity on MSFN around Win98SE

Good, but I still deprecate it

> [More DOS-topical : I never found a good DOS task switcher

Well, [un]surprisingly ... single-tasking design ?

> Caldera DR-DOS 7.03 has real pre-emptive multitasking (though
> requires its vaguely buggy EMM386) with TASKMGR

And it works well for you ? Sharing all resources (CPU, RAM, file I/O, screen space, network, keyboard&rat, sound, ...) is thoroughly designed, documented and implemented ?

PS: I'm leaving this absurdly bloated "Announce" thread with nothing about DOS now

EOD

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

> > Huh, how does it replace DV/X? Does it have job control or so?
>
> No (see "mostly"?),

The core feature not being supported is not "mostly". and..

> that was the point, you can't replace something when
> it's heavily undocumented (though Win16 is worse here).

.. afaik the DV/X function calls are in Ralph Brown. (IIRC 2F calls)

> > In my experience it about evens out on non-Windows. The larger
> datasegment
> > size on one hand, and the large number of registers and raised minimal
> > instruction level (and the systematic use of both in every library)
> about
> > cancel eachother.
>
> You don't need extra registers (use push/pop).

Slower since less pipelinable than non stalling reg operations. And the more regs, the more unnecessary stalls can be avoid.

> You don't need to assume
> SSE2 (use CPUID),

Double code generation unnecessary checks everywhere. And for what?

> which most compilers can't target anyways.

FPC can, GCC, MSVC can, Intel can afaik. Borland has not 64-bit compilers.

On 64-bit SSE2 is mandatory for FP, as per ABI. Original ABI's even deprecated FPU (and e.g. Windows XP/64 doesn't support it)

> Besides, there
> are ten bazillion extensions since SSE2 was a standard on all PCs (P4 -
> 2000, AMD64 - 2003): SSE3, SSSE3, SSE4.[12], AVX, etc. (Even new cpus don't
> have all these, not even close!)


Sure but except for SSE3 and AVX these are not that interesting. And as said it is the base level that is interesting, not the options. (SSE3 because it lowers SSE2 alignment requirements, and AVX, when it is supported (which it isn't) will double again). Probably in say 7 years we'll repeat this discussion for AVX

> Yes, in very rare cases, SSE2 can speed up
> an app significantly, but you don't need 64-bit for that.

Was not the point. The AES case was just an extreme example to offset your extreme answer.

My point was that while only a few percent, increased CPU requirement (and not just the theoretic possibility, but the fact that it is ACTUALLY used in all 64-bit software that you have, together with the few percent of the extra regs compensates the slowdown due to increased datasize in realworld code. Dr Dobbs has an interesting article about it.

> > > Why did they not implement V86 under long mode?
> >
> > One emulation only. 64-bit has 32-bit. 32-bit has 16-bit.
>
> 16-bit covers real mode (8086 - MS-DOS) and pmode (286 - OS/2 1.x), two
> entirely different things (though they both use segmentation).

I'm talking about V86 mode.

> I've heard conflicting reports (Ross Ridge, Bart Oldemann), so I'm not
> entirely sure if the cpu (long mode) itself or just the 64-bit OSes (Win64,
> Linux64) refuse to support one or both of those.

I've heard it repeated several times, not available in long mode. Afaik it is in the AMD manuals.

> > That next to nobody needs it is probably true too.
>
> The cpu and OS vendors are heavily tied together and make decisions
> (sometimes irrational) based upon one another (silly examples redacted).

And some people believe every conspirancy theory

> > And more importantly, if they add it now for a few 16-bit vigilantes,
> they
> > can't get rid of it till 2025. Keep in mind that 80386 was introduced in
> > 1985, and as an arch is only starting to be phased out.
>
> The 286 was still used until early '90s (according to Wikipedia).

Yes. But I'm not going to quibble over a few years. I think the win9x argument being dos is totally bogus though. Despite the few kb of heavily modified dos kernel here or there, users experienced as Windows, not as dos (safe for a few refuseniks)

> > > I don't ever (!) want them to remove 32-bit compatibility.
> >
> > I'm not that afraid about 32-bit EXEs running, but 32-bit OSes are in
> > danger due to the BIOS->EFI change.
>
> All new drivers (sigh), another drawback.

I don't understand this remark

> > Naah. The wrath of the long tail rules there. PE bins will run for quite
> > while within windows. And I guess 32-bit OSes will run for a handful of
> > years minimum too. Anyone who says that he can look forward longer than
> > that must be a multi-millionaire, since he would have bought a gazillion
> > Apple shares early this decennium if he could forsee IT that well.
>
> Of course they can't do it now. But give them five years.

Yup, there is a fair chance that then the situation will become neglected, and legacy bioses might be removed.

> As long as 50% of the people "don't care", they'll probably do it. I mean, > if they
> can't even keep NTVDM barely working on XP (2001-6), what makes you
> think WoW 32-bit will be any different??

Maybe the same will happen. It will be decent long enough to keep apps running a while. Games and other special software will be harder.

But Dos was a hard system to emulate. For the business apps it will be easier.

> > > Yes, modern PCs are crap.
> >
> > Sigh, more nagging and whining. What are you going to about it?
>
> What do you reasonably expect me to do about it?

I don't know. I can't entirely grasp a concept that seems illogical to me.

> Do you really think Win32 or FreeBSD64 is the answer?

No, since they go with mainstream. The point is more that I assume you have a plan if you insolate yourself :)

> Doubt it. And certainly you don't
> expect me to roll my own hardware (though presumably the 386 is patent
> free by now, maybe even 486, I dunno).

I think that is a bridge too far. The numbers have become to low I guess. (and the organisation level of Dos users is too low).

But buying in groups hardware that more or less does work is not too hard. Improve the support of Coreboot for that hardware to make it even better.

> (BTW, rr, was it intentional or not to leave me as moderator?

That was intentional.

---
Forum admin

> > that was the point, you can't replace something when
> > it's heavily undocumented (though Win16 is worse here).
>
> .. afaik the DV/X function calls are in Ralph Brown. (IIRC 2F calls)

Knowing the interface is (intentionally) not the same as knowing the implementation. I assume you understand this.

> > You don't need extra registers (use push/pop).
>
> Slower since less pipelinable than non stalling reg operations. And the
> more regs, the more unnecessary stalls can be avoid.

Slower? Barely (if at all). Push/pop has been fast, esp. since Pentium (two in one clock). How many free registers is enough, 16? 256? 512? 1024?

> > You don't need to assume SSE2 (use CPUID),
>
> Double code generation unnecessary checks everywhere. And for what?

You only have to "check" (CPUID) once at startup and use function pointers loaded appropriately, then you don't have to worry about anything.

And like I said, the obvious advantages from using SSE2 are few and far in between, so the code duplication is very very little (way less than 1 kb for paq8o8z for literally a 2x speedup).

BTW, paq8o8 isn't Win64 (LLP64?) friendly, though it compiles for Linux64 fine. Fun fun fun.

> > which most compilers can't target anyways.
>
> FPC can, GCC, MSVC can, Intel can afaik. Borland has not 64-bit compilers.

I don't think so. Most of them pale heavily (from what I've heard) in comparison to Intel (no surprise). At least GCC, in my very limited testing, wasn't even 5% effective.

> > I've heard conflicting reports (Ross Ridge, Bart Oldemann), so I'm not
> > entirely sure if the cpu (long mode) itself or just the 64-bit OSes
> (Win64,
> > Linux64) refuse to support one or both of those.
>
> I've heard it repeated several times, not available in long mode. Afaik it
> is in the AMD manuals.

Unless you really want to dig in or ask these guys themselves, I suggest you keep an open mind. Not that I ever expect anybody to fix it or do anything about it, but I guess it's possible. In general, I would trust a kernel hacker more than an average joe. (And BTW, I read on Wikipedia yesterday that WINE 64-bit does run Win16 apps. It didn't say anything about slow emulation. But I haven't tested. Most, if not all, Win 3.x apps are indeed pmode-friendly.)

Like I said, I only know that DOSEMU x86-64 has to full emulate 16-bit real mode stuff, from personal testing. It's very slow for that, annoyingly slow (so 64-bit's own alleged speedups overall doesn't cover that wound). However, DJGPP (32-bit) stuff is native speed (e.g. Quake). I never tested any 16-bit pmode stuff since that's relatively rare these days (oddly). I should test again one day soon just for curiosity (HXDEV16 ftw!).

> > > that was the point, you can't replace something when
> > > it's heavily undocumented (though Win16 is worse here).
> >
> > .. afaik the DV/X function calls are in Ralph Brown. (IIRC 2F calls)
>
> Knowing the interface is (intentionally) not the same as knowing the
> implementation. I assume you understand this.

Then how did we get Wine or FreeDOS?

> > Slower since less pipelinable than non stalling reg operations. And the
> > more regs, the more unnecessary stalls can be avoid.
>
> Slower? Barely (if at all). Push/pop has been fast, esp. since Pentium (two
> in one clock). How many free registers is enough, 16? 256? 512? 1024?

16 is a nice number.

> > Double code generation unnecessary checks everywhere. And for what?
>
> You only have to "check" (CPUID) once at startup and use function pointers
> loaded appropriately, then you don't have to worry about anything.

Except double code/maintenance, disabling of inlining in many places etc.

> And like I said, the obvious advantages from using SSE2 are few and far in
> between, so the code duplication is very very little (way less than 1 kb
> for paq8o8z for literally a 2x speedup).

paq is not a good example since the code is probably manually crafted for speed and has intense tight loops. I don't consider it general purpose app code.

> > FPC can, GCC, MSVC can, Intel can afaik. Borland has not 64-bit
> compilers.
>
> I don't think so. Most of them pale heavily (from what I've heard)
> in comparison to Intel (no surprise). At least GCC, in my very limited
> testing, wasn't even 5% effective.

Vectoring or simple FPU usage according to ABI is a different thing. I have to admit that I don't know all ins and outs of that either. I doubt SSE2 FP fully lives up to the IEEE standards

> > I've heard it repeated several times, not available in long mode. Afaik
> it
> > is in the AMD manuals.
>
> Unless you really want to dig in or ask these guys themselves, I suggest
> you keep an open mind. Not that I ever expect anybody to fix it or do
> anything about it, but I guess it's possible.

I think it is possible too, but the likeliness that it is, is too low to actually react to.

More importantly, a year or two back (when the first 64-bit Windows versions entered here), I gave up the last 16-bit binary. QEdit. Though I hadn't used it that much, usually using cygwin based JOE. It was more a motivation to dig a bit deeping into joe.

So now I only have BP7 and TS that I occasionally start. (as in less than one year). For that, an old win9x laptop serves me right. Still have to test these with wine, though in the past the integrated debuggers often made emulation hard..

> In general, I would trust a
> kernel hacker more than an average joe. (And BTW, I read on Wikipedia
> yesterday that WINE 64-bit does run Win16 apps. It didn't say anything
> about slow emulation. But I haven't tested. Most, if not all, Win 3.x apps
> are indeed pmode-friendly.)

Probably win32s apps.

> Like I said, I only know that DOSEMU x86-64 has to full emulate 16-bit real
> mode stuff, from personal testing. It's very slow for that, annoyingly slow
> (so 64-bit's own alleged speedups overall doesn't cover that wound).

Well. I guess it is enough to start up BP and browse around :)

> However, DJGPP (32-bit) stuff is native speed (e.g. Quake). I never tested
> any 16-bit pmode stuff since that's relatively rare these days (oddly). I
> should test again one day soon just for curiosity (HXDEV16 ftw!).

Hmm. Some code through a JIT, some not? Or do you use some specific version of some extender? Since DOSEMU needs to process the 16-bit extender startupcode too, even if the bulk is 32-bit ?

> AES is a special case because it requires a fairly hefty 64-bit integer
> calculation. IIRC SSE has no 64-bit integer. Only the 64-bit ALU has. (well
> and the FPU has comp, bu not logic operations)

Maybe, but in real use it will be limited by memory and IO speed. And current 32bit systems have already 64bit data bus. So you will not get +100% but less. I cannot guess, did you make some benchmark?

> If a related subject comes up I will. And if some parrot means to speak out
> the cliche "this is the year of the Linux desktop", I'll be the first to
> remember him of the fact that that is like the 10th or the 11th year in a
> row that was declared the year that Linux would make it onto the desktop.

They would probably ask you what you did for idea linux on desktop to be more real and when you'll answer that nothing they will be wondering why do you mentoring them...

> Well, you target one specific PC. And for PC high frequency silicon is
> already available, exempting you from the most difficult task. But the
> problem will also be which PC you exactly are going to emulate. For
> newergames you want high freq and fast graphics, while for old games you
> want a perfect timing emulation.

I think that most very old games are not problem to emulate under dosbox but some newer are atill hard to emulate smoothly, even on c2d @3,5GHz. Real power like ~ PIII would be needed.

I was talking with friend (coreboot coder) and he didn't know anything about intel core issue. They are more targeting on AMD because AMD gives them _complette_ specs (intel requires NDA for some low level things). Even he say that AMD has about 5 people who are coding for coreboot and they commited on SVN about 160000 lines of code. So there must be some intention of AMD. I quess they will replace BIOS with coreboot on future mobos. On other hand intel doesn't like coreboot and strictly pushes EFI. So it seems that DOS future depends on AMD and coreboot + seabios...

----------------------------------------------------------------

> $35 is far from a high price for any software. And it's been that way for
> quite a while. I bought my copy online in 2004 for the same price.
> But Novell DOS 7 (buggier DPMI) was like $125 in 1994. I think even PC-DOS 7
> was similarly priced (and I even saw that on eBay recently for like $50).
> So, relatively speaking, it's a bargain (assuming it works for your needs,
> of course).

I think it is for year 2011, maybe for 2004 would be ok. As I said I downloaded it free (for non-commercial use) from lineo, it might be in 2001-2002....

> Like I said, I only know that DOSEMU x86-64 has to full emulate 16-bit
> real mode stuff, from personal testing. It's very slow for that, annoyingly
> slow (so 64-bit's own alleged speedups overall doesn't cover that wound).
> However, DJGPP (32-bit) stuff is native speed (e.g. Quake). I never tested
> any 16-bit pmode stuff since that's relatively rare these days (oddly).
> I should test again one day soon just for curiosity (HXDEV16 ftw!).

It's a good new there's working 64bit port of DOSEMU :) I didn't hope they will do it. Pure realmode progs are usually older and doesn't need full power but it's fine that 32bit pmode progs runs fine - i think there are still some calls for 16bit functions from 32bit DJGPP programs but probably not so often that would cause big slowdown. So when it is possible for DOSEMU why not for NTVDM...

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

> > AES is a special case because it requires a fairly hefty 64-bit integer
> > calculation. IIRC SSE has no 64-bit integer. Only the 64-bit ALU has.
> (well
> > and the FPU has comp, bu not logic operations)
>
> Maybe, but in real use it will be limited by memory and IO speed. And
> current 32bit systems have already 64bit data bus.

Memory bus (L2/L3 to memory) or data bus (CPU to L1)?

The memory bus afaik has been 128-bit since NForce2 (when Dimms are installed in pairs)?

> So you will not get +100% but less. I cannot guess, did you make some benchmark?

See the DrDobbs article (may 2005 iirc). Since you have to do several 64-bit operations per loaded byte that split out into more than two 32-bit operands each, and access is in order, memory bus is not the issue. Sandy Bridge even adds hardware AES instructions to further improve performance.

It's a freak example, I know, but encryption and compression are slowly creeping in everywhere.

I btw also looked up the SSE2 vs SSE3 bit. Everything has SSE3 except first generation Athlon64 (754 socket). Even the 64-bit Pentium-D's do.

Still afaik most 64-bit compilers and ABIs still adhere strictly to SSE2 aligning requirements. Which shows again that the rough breaks now and then are healthy (at least IMHO)

> They would probably ask you what you did for idea linux on desktop to be
> more real and when you'll answer that nothing they will be wondering why do
> you mentoring them...

Well, I work on Lazarus of course. Moreover, that reasoning is flawed, _I_ didn't declare or echo the "year of Linux on the desktop" sentiment, so I don't have to defend it.

> I was talking with friend (coreboot coder) and he didn't know anything
> about intel core issue. They are more targeting on AMD because AMD gives
> them _complette_ specs (intel requires NDA for some low level things). Even
> he say that AMD has about 5 people who are coding for coreboot and they
> commited on SVN about 160000 lines of code. So there must be some intention
> of AMD. I quess they will replace BIOS with coreboot on future mobos. On
> other hand intel doesn't like coreboot and strictly pushes EFI. So it seems
> that DOS future depends on AMD and coreboot + seabios...

Interesting. Still that can change at any moment, but it at least means that current chipsets are still somewhat supported, even if only on the AMD side. (but that is enough)

>>> You don't need extra registers (use push/pop).

>> Slower since less pipelinable than non stalling reg operations. And the
>> more regs, the more unnecessary stalls can be avoid.

> Slower? Barely (if at all). Push/pop has been fast, esp. since Pentium (two
> in one clock). How many free registers is enough, 16? 256? 512? 1024?

Actually, these cycle counts are misleading, PUSH/POP effective lag will be dominated by access times to the memory hierarchy, which are much higher than CPU cycles - even to/from L1 cache, where the stack top will likely find its place. Thus when there is pressure on the general registers, PUSH reg/POP reg will incur significant performance penalties and is not a free substitute for more CPU registers

I find appalling that AMD/Intel did not build a way, be it awkward, to access the enlarged 64-bit registers in X86 mode, which would have been so immediately useful unlike the address size extensions that few people require. I'm sure you could easily think of ways to enhance the X86 binary operation encoding to allow for 64 bit operations on the 8 legacy registers, and hardly less easily allow access to the new ones (R8->R15), maybe not all at the same time, all that with minimal compatibility problems in 32 bit mode. But no, they didn't even try ! Drat!

--
Ninho

> >>> You don't need extra registers (use push/pop).
>
> >> Slower since less pipelinable than non stalling reg operations. And the
> >> more regs, the more unnecessary stalls can be avoid.
>
> > Slower? Barely (if at all). Push/pop has been fast, esp. since Pentium
> (two
> > in one clock). How many free registers is enough, 16? 256? 512? 1024?
>
> Actually, these cycle counts are misleading, PUSH/POP effective lag will be
> dominated by access times to the memory hierarchy, which are much higher
> than CPU cycles - even to/from L1 cache, where the stack top will likely
> find its place. Thus when there is pressure on the general registers, PUSH
> reg/POP reg will incur significant performance penalties and is not a free
> substitute for more CPU registers

I disagree. We may like more registers, but that's not realistic or else they would've done so by now. I hate to always bring up the past, but if we (and "real" pros) lived without it all these years, it can't be that unbearable.

> I find appalling that AMD/Intel did not build a way, be it awkward, to
> access the enlarged 64-bit registers in X86 mode, which would have been so
> immediately useful unlike the address size extensions that few
> people require. I'm sure you could easily think of ways to enhance the X86
> binary operation encoding to allow for 64 bit operations on the 8 legacy
> registers, and hardly less easily allow access to the new ones (R8->R15),
> maybe not all at the same time, all that with minimal compatibility
> problems in 32 bit mode. But no, they didn't even try ! Drat!

Perhaps they considered MMX/SSE as a workaround, who knows.

> > Knowing the interface is (intentionally) not the same as knowing the
> > implementation. I assume you understand this.
>
> Then how did we get Wine or FreeDOS?

There are unofficial "undocumented" books out there, as well as documented, but it's incomplete. Bugs still remain. Clean room reverse engineering helps, I guess, but even that can't do everything. Sometimes it's really just easier to rewrite/reinvent from scratch.

> How many free registers is enough, 16? 256? 512? 1024?
>
> 16 is a nice number.

You well know that 16 would never be "enough"!

> Except double code/maintenance, disabling of inlining in many places etc.

You're already doing double/triple/quadruple maintenance by supporting various platforms. But no, I'm talking about a tiny tiny portion of the code, having been profiled, not big chunks that don't affect the speed. And that's assuming your app even needs speed. Whatever happened to "computers are fast enough"??

> paq is not a good example since the code is probably manually crafted for
> speed and has intense tight loops. I don't consider it general purpose app
> code.

It's not for daily use, no, and I don't think it was tuned for speed (very slow, comparatively), only for academic curiosity. That's why I was impressed, that it managed to do so much and yet with a tiny tiny bit of code, speedup by 2x. But it's a rare example, most apps don't have such things.

> Vectoring or simple FPU usage according to ABI is a different thing. I have
> to admit that I don't know all ins and outs of that either. I doubt SSE2 FP
> fully lives up to the IEEE standards

SSE2 doesn't support the 80-bit precision?? Dunno, it's quite boring.

> Probably win32s apps.

Dunno, would have to test. But I don't think Win32s ever really caught on. Then again, I'm far from experienced in Win16, so I could be wrong.

> > However, DJGPP (32-bit) stuff is native speed (e.g. Quake). I never
> tested
> > any 16-bit pmode stuff since that's relatively rare these days (oddly).
> I
> > should test again one day soon just for curiosity (HXDEV16 ftw!).
>
> Hmm. Some code through a JIT, some not? Or do you use some specific version
> of some extender? Since DOSEMU needs to process the 16-bit extender
> startupcode too, even if the bulk is 32-bit ?

AFAICT, there's no JIT. I doubt it has specific workarounds for DJGPP proper ("GO32"), but who knows. No, it just fakes the BIOS and DOS calls and leaves the rest alone.

> be
> > dominated by access times to the memory hierarchy, which are much higher
> > than CPU cycles - even to/from L1 cache, where the stack top will likely
> > find its place. Thus when there is pressure on the general registers,
> PUSH
> > reg/POP reg will incur significant performance penalties and is not a
> free
> > substitute for more CPU registers
>
> I disagree. We may like more registers, but that's not realistic or else
> they would've done so by now.

"They" did, and upped the register count to 16 in the 64-bit version. For both integer (R8..R15) and SSE

> I hate to always bring up the past, but if we
> (and "real" pros) lived without it all these years, it can't be that
> unbearable.

People have lived without computers for millenia, but that doesn't mean I'll toss out mine.

> > I find appalling that AMD/Intel did not build a way, be it awkward, to
> > access the enlarged 64-bit registers in X86 mode, which would have been
> so
> > immediately useful unlike the address size extensions that few
> > people require. I'm sure you could easily think of ways to enhance the
> X86

If you see what made it to endusers, it is all server processor features backported to consumer. That's why most users now have several cores idling.

64-bit is no different. Server systems, specially databases really needed more address space, and that was the whole motiviation of doing this, and the rest is extra because they had a first chance since essentially the i386 in 1985 to force backwards incompat changes. (since the opcodes needed to change to make more room for the extra register bit)

Just like with i386 they also increased the orthogonality more, so that you can now read (R/E)IP

> > binary operation encoding to allow for 64 bit operations on the 8 legacy
> > registers, and hardly less easily allow access to the new ones
> (R8->R15),
> > maybe not all at the same time, all that with minimal compatibility
> > problems in 32 bit mode. But no, they didn't even try ! Drat!
>
> Perhaps they considered MMX/SSE as a workaround, who knows.

The SSE instructions are separate. For the integer regs they needed to change existing opcodes and add an extra bit to the register encoding, something that cannot be done without breaking backwards compat.

This thread degenerated

---
DOS-u-akbar!

>
> 16-bit covers real mode (8086 - MS-DOS) and pmode (286 - OS/2 1.x), two
> entirely different things (though they both use segmentation).

> I've heard conflicting reports (Ross Ridge, Bart Oldemann), so I'm not
> entirely sure if the cpu (long mode) itself or just the 64-bit OSes (Win64,
> Linux64) refuse to support one or both of those.

I've searched about this, and long mode supports 16-bit protected mode, but not real mode.

There are also some hints that this goes for pure application code only, and that operating system (and I assume extenders) level code might not work (e.g. the unavailability of certain TSS features in long mode).

Since afaik win16 apps are pmode, they may indeed run technically, but win64 doesn't support it.

Afaik Linux never had support for 16-bit pmode.

> >
> > 16-bit covers real mode (8086 - MS-DOS) and pmode (286 - OS/2 1.x), two
> > entirely different things (though they both use segmentation).
>
> > I've heard conflicting reports (Ross Ridge, Bart Oldemann), so I'm not
> > entirely sure if the cpu (long mode) itself or just the 64-bit OSes
> (Win64,
> > Linux64) refuse to support one or both of those.
>
> I've searched about this, and long mode supports 16-bit protected mode, but
> not real mode.
>
> There are also some hints that this goes for pure application code only,
> and that operating system (and I assume extenders) level code might not
> work (e.g. the unavailability of certain TSS features in long mode).
>
> Since afaik win16 apps are pmode, they may indeed run technically, but
> win64 doesn't support it.
>
> Afaik Linux never had support for 16-bit pmode.
How about this?
http://v86-64.sourceforge.net/

> How about this?
> http://v86-64.sourceforge.net/

Interesting. I currently don't have any machine with 64bit linux but maybe good in future...

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

BTW interesting debug fuctions of AMD CPU
http://czerno.tk/

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