3 ms·

This is something I was able to achieve independently back in 2001 by writing a small DOS program that switched CPU into 32-bit protected mode, loaded a PE (por

This is something I was able to achieve independently back in 2001 by writing a small DOS program that switched CPU into 32-bit protected mode, loaded a PE (portable executable) exe file into the memory together with DLL modules it depended upon. The next step was to write KERNEL32.dll etc modules that were used by executable files of interest. It turned out to be a relatively easy task - only a handful of Win32 modules and their API functions were actually used by the real programs I was trying to run under the DOS. And those API implementations were mostly stubs that translated, say, I/O calls from a program into corresponding DOS calls. Having that trick upon my sleeve, I vividly remember of being able to run 32-bit Borland C++ compiler (bcc32.exe) and linker for Windows under the raw DOS environment. Don't ask why, I did it because I could.

anonymousiam 3y ago
Okay, I won't ask why you did it, but I know I would have liked to run their IDE under DOS instead of Windows. Back in that era, Windows was very slow and clunky, and I was pretty unhappy when I "upgraded" to Borland 4.0 (IIRC) which required Windows. Fortunately, I switched to Linux around the same time.
- garganzol 3y ago
  I had similar intentions - I was deep into OS development back then, so I wanted to have a 32-bit C/C++ compiler that would effortlessly target 80386+ CPUs. Borland C++ was my favorite one because it supported official x86 assembly syntax (Intel). In contrast, GNU tools of the day had their own kinky x86 syntax which made me uneasy. It so happened that the Borland compiler that was able to target a 32-bit CPU, required a 32-bit CPU itself to run. DOS only provided 16-bit environment. That's why I went to those lengths of writing a custom 32-bit PE loader that would allow me to run some 32-bit Windows applications right under the DOS. DOS was a preferable environment because it was fast and allowed booting your own OS kernels without doing a full computer reboot - you just ran an executable loader and it took control away from the DOS and gave it to your OS. And then when you "exited" your OS, instead of rebooting, it was returning back to the DOS provided that the OS kernel you were running was careful enough to preserve/restore the RAM content upon exit. It gave a huge productivity boost back then. Later, however, I switched to Windows and was using Bochs (open-source x86 PC emulator) to effortlessly run the OS I was working on.
  - pjmlp 3y ago
    I never could stomach the inline Assembly syntax from GNU tools, having been educated in Borland and Microsoft compilers. Nowadays, if I would have to write that kind of code, I would rather use intrisics or go to the trouble of using an external Assembler.
    - garganzol 3y ago
      I once asked GNU people why they had such weird non-standard syntax for inline x86 assembly. Their answer was that the GNU syntax was just easier to implement in their existing toolchain of the day. Their big idea was to have a semi-universal implementation of the assembler where a particular CPU syntax was just a small, mostly declarative piece of code and configuration. The support of the canonical Intel syntax for x86 assembly would require significantly more efforts. As far as I know, the idea of a weird but universal assembly syntax came from the original Unix developed by AT&T. My take was: come on, it's just a syntax, a relatively miniscule effort required to implement the idiomatic x86 assembly support is nothing compared to pains a custom non-standard syntax may give to people.
justsomehnguy 3y ago
> Don't ask why, I did it because I could. The most amusing was when you start something and by some minor things you understood what the thing is doing something weird, in a good sense. Later it was when a win32 app announce what it has a merit just by being not a square one. Good times.

anonymousiam 3y ago

Okay, I won't ask why you did it, but I know I would have liked to run their IDE under DOS instead of Windows. Back in that era, Windows was very slow and clunky, and I was pretty unhappy when I "upgraded" to Borland 4.0 (IIRC) which required Windows. Fortunately, I switched to Linux around the same time.

garganzol 3y ago
I had similar intentions - I was deep into OS development back then, so I wanted to have a 32-bit C/C++ compiler that would effortlessly target 80386+ CPUs. Borland C++ was my favorite one because it supported official x86 assembly syntax (Intel). In contrast, GNU tools of the day had their own kinky x86 syntax which made me uneasy. It so happened that the Borland compiler that was able to target a 32-bit CPU, required a 32-bit CPU itself to run. DOS only provided 16-bit environment. That's why I went to those lengths of writing a custom 32-bit PE loader that would allow me to run some 32-bit Windows applications right under the DOS. DOS was a preferable environment because it was fast and allowed booting your own OS kernels without doing a full computer reboot - you just ran an executable loader and it took control away from the DOS and gave it to your OS. And then when you "exited" your OS, instead of rebooting, it was returning back to the DOS provided that the OS kernel you were running was careful enough to preserve/restore the RAM content upon exit. It gave a huge productivity boost back then. Later, however, I switched to Windows and was using Bochs (open-source x86 PC emulator) to effortlessly run the OS I was working on.
- pjmlp 3y ago
  I never could stomach the inline Assembly syntax from GNU tools, having been educated in Borland and Microsoft compilers. Nowadays, if I would have to write that kind of code, I would rather use intrisics or go to the trouble of using an external Assembler.
  - garganzol 3y ago
    I once asked GNU people why they had such weird non-standard syntax for inline x86 assembly. Their answer was that the GNU syntax was just easier to implement in their existing toolchain of the day. Their big idea was to have a semi-universal implementation of the assembler where a particular CPU syntax was just a small, mostly declarative piece of code and configuration. The support of the canonical Intel syntax for x86 assembly would require significantly more efforts. As far as I know, the idea of a weird but universal assembly syntax came from the original Unix developed by AT&T. My take was: come on, it's just a syntax, a relatively miniscule effort required to implement the idiomatic x86 assembly support is nothing compared to pains a custom non-standard syntax may give to people.

justsomehnguy 3y ago

> Don't ask why, I did it because I could. The most amusing was when you start something and by some minor things you understood what the thing is doing something weird, in a good sense. Later it was when a win32 app announce what it has a merit just by being not a square one. Good times.