Given that this is in "Vintage Computer Programming" and he asks about reading DMF in PDOS/386, I don't think he wants to boot from those disks, nor actually install Windows 95. He's just looking for a way to read 21 sectors.
Otherwise, if the hardware was appropriate for Windows 95, it would have a floppy controller on-board and he would not have to rely on USB.
Mostly correct - since I am creating a competitor to Windows I want to make sure that I am as squeaky clean as possible.
So Win95 is the reference - I want to make sure all my applications run on both PDOS/386 and Win95 (and thus above - as I also check that they still work on Win10).
I have gone through the license agreements looking for any indication that I can't use Microsoft products to make a competitor of Microsoft. So far I haven't seen such a thing in either Win95 or MASM 6.11. But I'm still waiting for a boxed Visual C++ 1.52C and 2.0 or 4.0 to arrive so that I can check them. I've seen restrictions on the freely available Microsoft compilers saying that the executables you produce can't be used on non-Microsoft systems. But not on the commercial ones. I ran into a problem where a some products say to read the license agreement on a website, and that link no longer has my old version.
I have bought something like US$4000 worth of mostly software, mostly Microsoft, from ebay over the last few months. Still, cheaper than a car, and a small part of the imputed labor costs over the last 30 years of development of PDOS.
It is only recently that I have attempted to build PDOS/386 and PDOS/86 with Microsoft tools.
However - I was planning on using/booting Win95 - but under Virtualbox or qemu.
Oh yeah - I do have Windows 95 on CD already - with a key too - but the CD says "for distribution with a new PC only". At some level I am erring on the side of paranoia, so I decided I may be able to be pinged for that too, so decided to buy one without such a restriction.
I'm also getting DOS 6.22. An upgrade version - I haven't seen a full version on ebay. But ... upgrade from what? Well, the pack says I can upgrade from DOS "or compatible" - does PDOS itself count as "compatible"? Who knows what a judge will rule. But the pack also says I can upgrade from OS/2. So I bought an unrestricted OS/2 1.2. I also bought an OS/2 2.0 which turned out to be an upgrade (that wasn't visible on the pack - it was hidden by a sticker), so OS/2 1.2 enabled that to install. I'm not actually using that though - I bought ArcaOS so that I had a commercially-supported rival to Windows. Getting Win32 on it is tricky though. It comes with "pec", but that will only run one Win32 console mode program, not spawn another, and I don't get ANSI output, nevermind input.
BTW - that is actually an interesting model. You can write C90-compliant programs that work on basically all platforms (including IBM mainframes), but you only get command line programs.
Now there is ANSI X3.64 for terminals - so you should be able to write fullscreen apps in a portable manner also. But it seems MSDOS, Windows and mainframes have gone to a lot of effort to suppress that.
I have bypassed the restrictions and deficiencies in all of them in PDOS/86, PDOS/386 and z/PDOS, such that Microemacs 3.6 gives an editor on all of those environments with the exact same source code other than I had to account for EBCDIC ESC being a different codepoint, and the C90 standard doesn't provide a CHAR_ESC define for me. Plus some other EBCDIC differences like the control codes.
The ANSI X3.64 standard allows a terminal to send two ESC when the user presses a real ESC, instead of relying on a non-standard timeout (which wouldn't exist if input was being redirected anyway), so PDOS does that too - allowing the portability.
The Commodore Amiga might have been more successful if IBM PC programmers had been writing their fullscreen applications in a portable manner so that supporting the Amiga required nothing more than a recompilation. That is probably ultimately what I have been doing for almost 40 years - trying to find out the underlying barrier to the Amiga being a viable alternative. Another thing that is cited is that ANSI.SYS was slow - but I think if that had been replaced by something that did direct screen writes (as the apps themselves ended up doing for speed), instead of ANSI.SYS doing DOS and then MSDOS doing BIOS calls, that may well have solved the problem. I haven't attempted to prove that theory by finding/writing an ANSI.SYS and run it on an XT (which I no longer have) - but maybe the new laptop I have on order with a V20 could answer that question - but I really need some proper period machines, and the software. And answering that question isn't priority at the moment for me anyway.
