3 ms·

How "compatible" is it with MS-DOS? Can it run 16-bits DOS applications?

by natas 4y ago

rep_lodsb 4y ago
Only the 16 bit version, and probably not very well, you're better off running literally any other DOS instead. PDOS is all written in C with little or no assembly code (like FreeDOS, but unlike MS-/DR-/PTS-DOS), and worse than that the 16 bit version is compiled in the "huge" memory model which sort of simulates a flat address space. That means basically any pointer operation generates several extra instructions. Because the author feels that segmented memory should not exist and is something that can be ignored, even on 16 bit x86. The author is - IMO - a kook¹, who among other things is obsessed with UNIX and C90 (no other version!). His only problem with Linux/BSD is that they use communist free software licenses instead of being public domain, which supports TRUE capitalist freedom. His OS will be the one to restart technological civilization after a nuclear war. ¹ I might be one too, and I haven't even seriously started on writing my own OS, which will use segmented memory in the 80286's protected mode, be written exclusively in assembly for the kernel and Pascal for userland, and do it's utmost to not accomodate UNIXisms and the horrible C programming language, while still being compatible with DOS.
- lproven 4y ago
  > The author is - IMO - a kook¹, From many long threads on the Hercules/OS380 list, I would have to agree with you. I suggested many profitable, interesting, relevant lines of research he should read about. Not use, even, just investigate, as they were highly relevant to his plans. Nope. They were all dismissed as evil possible communist mind-poison. :shrug: In the end, I just left the list, which I almost never do.
- kerravon86 4y ago
  The huge memory model supposedly has a 4% overhead in practice, cited by someone who did such programming under OS/2. Personally I wasn't able to detect any slowdown at all, which is not surprising, because you are normally expected to be bottlenecked on some application doing some calculation, not the OS. I am not aware that I have any obsession with Unix. For PDOS/386, PDOS/86 and PDOS-generic I use an API inspired by MSDOS. For z/PDOS I use the MVS API. I specifically don't want anything to do with Posix which mandated fork() but didn't provide for simple memory allocation.
kerravon86 4y ago
Source or binary? In both cases - it depends. PDOS/86 will certainly run some binaries. But if you say "what about xyz" the answer is likely "probably not". I don't have a lot of interest in 16-bit, so it's there for demonstration purposes mainly. My interest is 32-bit. The biggest genuine task I do is getting GCC to compile itself with full optimization, which requires something like 23 MB of memory on the mainframe and something like 37 MB on a PC. Far far below the 4 GiB barrier (or even 2 GiB barrier), but above even 16 MiB, nevermind 640k. If it is source code you have, then it will require recompilation at a minimum. I made use of that fact to provide a C-defined API to wrap the INT calls, so at least nominally you need to use those C functions. But you may be able to get away with an existing int86x call (or even assembler instruction), as the interrupts do exist (ie even in 32-bit). If your MSDOS program is C90-compliant then that should work unchanged - but that is the case for any environment, not just MSDOS or PDOS/386.

How "compatible" is it with MS-DOS? Can it run 16-bits DOS applications?

by natas 4y ago

How "compatible" is it with MS-DOS? Can it run 16-bits DOS applications?

Only the 16 bit version, and probably not very well, you're better off running literally any other DOS instead. PDOS is all written in C with little or no assembly code (like FreeDOS, but unlike MS-/DR-/PTS-DOS), and worse than that the 16 bit version is compiled in the "huge" memory model which sort of simulates a flat address space. That means basically any pointer operation generates several extra instructions. Because the author feels that segmented memory should not exist and is something that can be ignored, even on 16 bit x86. The author is - IMO - a kook¹, who among other things is obsessed with UNIX and C90 (no other version!). His only problem with Linux/BSD is that they use communist free software licenses instead of being public domain, which supports TRUE capitalist freedom. His OS will be the one to restart technological civilization after a nuclear war. ¹ I might be one too, and I haven't even seriously started on writing my own OS, which will use segmented memory in the 80286's protected mode, be written exclusively in assembly for the kernel and Pascal for userland, and do it's utmost to not accomodate UNIXisms and the horrible C programming language, while still being compatible with DOS.

lproven 4y ago
> The author is - IMO - a kook¹, From many long threads on the Hercules/OS380 list, I would have to agree with you. I suggested many profitable, interesting, relevant lines of research he should read about. Not use, even, just investigate, as they were highly relevant to his plans. Nope. They were all dismissed as evil possible communist mind-poison. :shrug: In the end, I just left the list, which I almost never do.
kerravon86 4y ago
The huge memory model supposedly has a 4% overhead in practice, cited by someone who did such programming under OS/2. Personally I wasn't able to detect any slowdown at all, which is not surprising, because you are normally expected to be bottlenecked on some application doing some calculation, not the OS. I am not aware that I have any obsession with Unix. For PDOS/386, PDOS/86 and PDOS-generic I use an API inspired by MSDOS. For z/PDOS I use the MVS API. I specifically don't want anything to do with Posix which mandated fork() but didn't provide for simple memory allocation.

kerravon86 4y ago

Source or binary? In both cases - it depends. PDOS/86 will certainly run some binaries. But if you say "what about xyz" the answer is likely "probably not". I don't have a lot of interest in 16-bit, so it's there for demonstration purposes mainly. My interest is 32-bit. The biggest genuine task I do is getting GCC to compile itself with full optimization, which requires something like 23 MB of memory on the mainframe and something like 37 MB on a PC. Far far below the 4 GiB barrier (or even 2 GiB barrier), but above even 16 MiB, nevermind 640k. If it is source code you have, then it will require recompilation at a minimum. I made use of that fact to provide a C-defined API to wrap the INT calls, so at least nominally you need to use those C functions. But you may be able to get away with an existing int86x call (or even assembler instruction), as the interrupts do exist (ie even in 32-bit). If your MSDOS program is C90-compliant then that should work unchanged - but that is the case for any environment, not just MSDOS or PDOS/386.