DOS ain't dead

Assuming I had followed these rules: https://en.wikipedia.org/wiki/Protected_mode This was not without its limitations. If an application utilized or relied on any of the techniques below, it would not run: Segment arithmetic Privileged instructions Direct hardware access Writing to a code segment Executing data Overlapping segments Use of BIOS functions, due to the BIOS interrupts being reserved by Intel[31] In reality, almost all DOS application programs violated these rules ... what could I actually do, assuming I had an 80286 computer? "binary compatibility with real-mode code" - sounds good. "the ability to access up to 16 MB of physical memory, and 1 GB of virtual memory" - sounds good. But ... WHERE? Is this something I could do on OS/2 1.x? With an MZ executable? A .com? What are they advertising? NE executables didn't exist except on MSDOS 4.0, which may or may not buy something. Is that what they are advertising? I didn't use OS/2 1.x, but it may have had an MSDOS window and an MSDOS fullscreen (as modern OS/2 does). Did something work on either of those if you followed "the rules"? As opposed to a program that DIDN'T follow the rules, e.g. it wouldn't run in the window, and you were forced to use the fullscreen. I've heard of something called the "penalty box" or "sin bin" for badly-behaved programs running on OS/2? Something like that? Or did they decide that there were so few programs that obeyed the rules, that no-one actually built anything to accommodate programs that had followed the rules? Or was the problem that MSDOS itself had used segment arithmetic in the MZ executable format such that it was not possible to run an unmodified MZ executable (at least one with more than 64k of code), in protected mode, no matter how well behaved the actual code was? Thanks. Paul.

> "the ability to access up to 16 MB of physical memory, and 1 GB of virtual > memory" - sounds good. > > But ... WHERE? > > Is this something I could do on OS/2 1.x? > > With an MZ executable? A .com? > > What are they advertising? > > NE executables didn't exist except on MSDOS 4.0, > which may or may not buy something. Is that what > they are advertising? Yes. NE binaries support both real-mode and protected-mode apps. The 1 GB of virtual memory, I guess that's just the theorectical limit of 8192 LDT and 8191 GDT descriptors, each with limit -1, meaning 64 kB.

---
MS-DOS forever!

> Yes. NE binaries support both real-mode and protected-mode apps. Probably because Windows 3.0 (1990) still (partially) supported 8086.

> > NE executables didn't exist except on MSDOS 4.0, > > which may or may not buy something. Is that what > > they are advertising? > > Yes. NE binaries support both real-mode and protected-mode apps. The 1 GB > of virtual memory, I guess that's just the theorectical limit of 8192 LDT > and 8191 GDT descriptors, each with limit -1, meaning 64 kB. Ok, thanks. So - there were compilers/linkers capable of building NE executables in the late 1980s. MSDOS 4.0 was not available for purchase as far as I know. Windows 3.0 on an 8086 could execute NE executables I think, but you couldn't do an INT 21H to write to stdout. So - as a law abiding citizen, who wanted to follow Intel's 8086 rules so that I would be in pole position when the IBM PC AT came out - how exactly was I supposed to write an MSDOS application in say Dec 1983 (when MSDOS 2.0 was available, and the 80286 was available, but before the IBM PC AT had actually shipped), so that as soon as I got my hands on an IBM PC AT (in 1984), I could whip up a protected mode 16-bit OS and run my *existing* MSDOS binaries (that followed the rules)? Or if not Dec 1983 - WHEN could I do ANYTHING sensible? What's the point of spending all that effort to follow the rules if it buys me NOTHING? Or rather - what needed to happen so that law-abiding citizens got rewarded for all their effort? Can you create a timeline or game plan that would benefit those who spent the effort to follow rules? Thanks. Paul.

> https://en.wikipedia.org/wiki/Protected_mode > > This was not without its limitations. If an application utilized or relied > on any of the techniques below, it would not run: > > Segment arithmetic Segment arithmetic IS a limitation. A workaround to soften the pain of only being able to access 64k at a time by allowing those 64k to start at any multiple of 16 bytes. Being able to use 32-bit offsets directly is much better. > Privileged instructions > Direct hardware access This is configurable. You can use protected mode to tap or block direct I/O, but you can also give protected mode tasks full permissions for all I/O ports. Many instructions which are privileged did not even exist on 8086. They are privileged to make it possible to prevent tasks from interfering with each other. > Writing to a code segment This also is configurable: https://en.wikipedia.org/wiki/Segment_descriptor As far as I remember, write-protected code segments became the default for Windows much later than Win9x, because app writers were used to overwriting code :-p > Executing data > Overlapping segments Both probably is a misunderstanding: You can easily use the same area of memory for code and data, but you may have to use different segment descriptors. Nobody stops you from letting segment descriptors point to identical or at least overlapping areas of RAM. You even get the flexibility to let the areas start at any offset instead of only multiples of 16 bytes like on 8086. However, the segment length has to be a multiple of 4 kB if you want it to be more than 1 MB. Operating systems with paging will want you to set both length and offset to multiples of 4 kB. > Use of BIOS functions, due to the BIOS interrupts being reserved by > Intel[31] Very few PC designs kept the first 32 interrupts reserved for the CPU. I think the TI Professional PC did. However, most BIOSes will not like being called directly in protected mode. On the other hand, VESA VBE graphics BIOS explicitly offer a protected mode entry point. > In reality, almost all DOS application programs violated these rules Because of this, you have VM86 hardware support which makes it relatively easy for operating systems and even for drivers like EMM386 to create a task which runs believing that it would be running NOT in protected mode. To make old apps happy. > ... what could I actually do, assuming I had an 80286 computer? You can compile your apps to use protected mode to use all the advantages, or run your apps in real mode or in a VM86 task without having to change them. > "binary compatibility with real-mode code" - sounds good. You can either stay away from protected mode or use a VM86 host for that. > "the ability to access up to 16 MB of physical memory, and 1 GB of virtual > memory" - sounds good. You will have to use protected mode for that. With 386, even the 16 MB limit no longer applies. > But ... WHERE? With a DOS Extender or by using any protected mode operating system of your choice. > Is this something I could do on OS/2 1.x? Probably. > With an MZ executable? A .com? Only with a DOS Extender. > What are they advertising? Hardware features. To use them, you would have to use them. > NE executables didn't exist except on MSDOS 4.0, > which may or may not buy something. Is that what > they are advertising? Probably not. I do not think MS DOS directly supported protected mode EXE files. So you still had to use a DOS Extender and you can use most of those with MSDOS 3.xx already. > I didn't use OS/2 1.x, but it may have had an > MSDOS window and an MSDOS fullscreen (as modern > OS/2 does). Probably, but if you only want MS DOS apps, then you have no need to buy OS/2 or Windows. Unless you want to run several of them in parallel, in multiple windows. But then you will be limited by how well OS/2 and Windows can keep them from interfering with each other, because DOS apps were not originally meant to be run like that. > Or was the problem that MSDOS itself had used > segment arithmetic in the MZ executable format > such that it was not possible to run an > unmodified MZ executable (at least one with > more than 64k of code), in protected mode, no > matter how well behaved the actual code was? I doubt that anybody would recommend to run any DOS app as-is directly in protected mode. That is exactly what VM86 mode is for: To create an illusion of "everything is as in those good old 8086 times" for old DOS apps. If you want to use NEW features, you also have to compile your apps to know them. Anyway, https://wiki.syslinux.org/wiki/index.php?title=Doc/comboot is an example of running a limited subset of DOS com binaries outside an actual DOS, so you might enjoy hearing about those. They are run in real mode, though. The SYSLINUX family of boot loaders and boot menus does not provide VM86 services.

---
FreeDOS / DOSEMU2 / ...

> Or rather - what needed to happen so that law-abiding > citizens got rewarded for all their effort? > > Can you create a timeline or game plan that would > benefit those who spent the effort to follow rules? The most beneficial plan would have been to: - Wait a few years - Recompile for the desired target (be that Unix, OS/2 or Win32, probably depending on the time frame envisioned) Because to the producer of the software, binary compatibility is a minuscule benefit.

> multiple of 16 bytes. Being able to use 32-bit offsets directly is much > better. > > You can either stay away from protected mode or use a VM86 host for that. Neither of those things existed on the 80286. My question is restricted to the 80286, if that wasn't clear. I will digest the rest of your message though to see if that is what Intel expected to happen. BFN. Paul.

> > Or rather - what needed to happen so that law-abiding > > citizens got rewarded for all their effort? > > > > Can you create a timeline or game plan that would > > benefit those who spent the effort to follow rules? > > The most beneficial plan would have been to: > > - Wait a few years > - Recompile for the desired target (be that Unix, OS/2 or Win32, probably > depending on the time frame envisioned) > > Because to the producer of the software, binary compatibility is a > minuscule benefit. I'm intending to follow the rules, publish a binary, lose the source code, and then die. And I want my users to get the benefit of me being law-abiding, even though I'm lousy at source control and watching for buses when I cross the road. BFN. Paul.

I think we are talking cross-purposes. Wikipedia says: > > In reality, almost all DOS application programs violated these rules As opposed to: Because no DOS-extenders existed, it doesn't make any difference whether a DOS program followed Intel's rules or not, because any code that was written needed to be recompiled into the DOS extender format or to some other OS format. In fact, everyone here at Wikipedia thinks that Intel must have been on the wacky weed when they wrote their irrelevant (as opposed to difficult to follow and rarely followed) rules. > With a DOS Extender or by using any protected mode operating system of your > choice. Which, as above, makes the rules irrelevant. BFN. Paul.

> > Writing to a code segment > > This also is configurable: > https://en.wikipedia.org/wiki/Segment_descriptor > > As far as I remember, write-protected code segments became the default for > Windows much later than Win9x, because app writers were used to overwriting > code :-p If you would reference the descriptor format you would notice that the "WR" bit means "writeable" for data descriptors but "readable" for code descriptors. You cannot execute from a data descriptor loaded as CS, only a code descriptor. So you cannot ever write with a cs: segment override prefix in Protected Mode, because CS must be loaded from a code descriptor and you cannot write to segments loaded from a code descriptor. (Loading the selector in CS to another segment register will still load the code descriptor so even that doesn't suffice to write. You need a writeable data descriptor instead. This, of course, can have the same base as the code descriptor, aliasing the same memory.) More generally on the topic of this thread, following the rules makes it easier to port a program to also run in Protected Mode. A good example is the original Debug/X as well as lDebug/X and its Extensions for lDebug. Most of their code is bimodal, it can run either in Real/Virtual 86 Mode or in a 16-bit CS in Protected Mode. Following the rules in this case means not writing with the CS override / not using the selector in CS to try to write to the application's code segment. (Instead of pushing/moving CS to get the code segment into a data segreg, the original Debug/X was adjusted to push/mov SS instead. In lDebug/X this is needed in 86 Mode as well because even then SS != CS as we now use a stack/data/entry segment at another base address than the code segment(s).) Also, using special purpose functions like setes2dx to address 86 Mode segments, which assembles to just mov es, dx in non-DPMI lDebug, but will set a scratch selector to address this 86 Mode segment while lDebugX is in PM. All segment arithmetic must be done using such filters and not depending on segregs holding Real Address Mode segment addresses. Some interrupt and function calls must go through Protected Mode int 31h functions to call down to the 86 Mode handlers. There are functions like selector_to_segment which must operate on a variable in memory or in a non-segreg register because segregs in PM can only hold valid selectors or 0000h. (This function will retrieve the segment base from the descriptor and return the 86 Mode segment that corresponds to this base. For this to be valid the selector must be referring to a 86 Mode segment base address, ie have a base of linear 0 to linear 0FFFF0h on a paragraph boundary.) The AMIS common functions are easy to work with calling down from PM because they pass all segment values in non-segreg registers, so they need less special setup in the PM caller. For instance, the AMIS detection callout passes the segment in DX so the relatively simple call_int2D function can be used. In some of the AMIS private functions of lDebug I also followed this example. The notable exception is function 30h which consequently requires more setup to call from PM, involving the selector_to_segment function.

---
l

> So - there were compilers/linkers capable of building > NE executables in the late 1980s. The MS Word v5.5 binary is such a "family application", running both in DOS and OS/2 1.X.

---
MS-DOS forever!

> The MS Word v5.5 binary is such a "family application", running both in DOS > and OS/2 1.X. As is MASM 5.

> This was not without its limitations. If an application utilized or relied > on any of the techniques below, it would not run: > > ... > Use of BIOS functions, due to the BIOS interrupts being reserved by > Intel[31] I would classify "Would not run" as a vast overstatement. Specifically regarding the BIOS functions, that is not actually a DOS problem -- it is a BIOS problem. And even then, the only BIOS interrupt problem I've come across that has any practical effect is INT 05, which used by both the BIOS PrintScreen function and by the CPU BOUND instruction (which didn't even exist until the 80286).

> > This was not without its limitations. If an application utilized or > relied > > on any of the techniques below, it would not run: > > > > ... > > Use of BIOS functions, due to the BIOS interrupts being reserved by > > Intel[31] > > I would classify "Would not run" as a vast overstatement. Specifically > regarding the BIOS functions, that is not actually a DOS problem -- it is a > BIOS problem. And even then, the only BIOS interrupt problem I've come > across that has any practical effect is INT 05, which used by both the BIOS > PrintScreen function and by the CPU BOUND instruction (which didn't even > exist until the 80286). You can do BIOS calls from PM16? ie read a disk? edit: and into memory above 1 MiB?