[HN Gopher] 32-Bit DOS Applications
___________________________________________________________________
32-Bit DOS Applications
Author : mariuz
Score : 44 points
Date : 2023-05-11 07:37 UTC (15 hours ago)
(HTM) web link (www.youtube.com)
(TXT) w3m dump (www.youtube.com)
| liendolucas wrote:
| Oh boy, when you see those game requirements. Today gamers would
| change GPUs not every year or so but kind of. Those software
| rendering engines are true gems because the guys who worked on
| them literally pushed CPU and RAM to their limits and beyond. Is
| also a reminder of how much you can do with so little. I highly
| respect and admire people that grew up chewing up assembly during
| the 80's and 90's, wished I had that pleasure.
| jmclnx wrote:
| Microsoft c/c++ 7.0 compiler/linker is a 32bit application. I
| still have it and hope to see if I can get it working under
| FreeDOS. The docs are great.
| markus_zhang wrote:
| https://winworldpc.com/res/img/screenshots/29213296f35729c46...
|
| Man this is good time. I wish nowadays we has such
| documentations.
| tambourine_man wrote:
| Aside from the software, I'd love a modern version of this laptop
| too. Sturdy keys with lots of travel, just the right screen size.
| Imagine a unibody built of this form factor, with modern SSD and
| RAM. The amount of battery one could fit in at that thickness
| would last you a week in a single charge.
| tambourine_man wrote:
| We really did have everything, didn't we? I mean, when you think
| about it.
| pavlov wrote:
| With 32-bit DOS extenders, VESA VGA BIOS extensions and Gravis
| Ultrasound, we really did have everything -- except an
| operating system. Who needs one anyway.
| mysterydip wrote:
| All it was missing was an (optional) network stack, IMHO
| com2kid wrote:
| Turns out they just get in the way, and in-between showing
| ads, sell your usage data to advertising companies.
|
| We were better off without them.
| anyfoo wrote:
| Don't be trite in a technical conversation. While I agree
| that those things are bad, it adds nothing here, and
| besides only a minority of Operating Systems does what you
| say.
| anyfoo wrote:
| Yeah. Until we wanted multitasking. Separate address spaces,
| shared resources, protection, eventually security. That's
| when the "operating system" came in. DOS was allowed to live
| as a virtualized task, but it wasn't the same.
|
| I did get tambourine_man's reference, though. Nice!
| linguae wrote:
| Though, there's a way we can enjoy a minimal operating
| system yet also have security, protection, and resource
| management:
|
| https://en.m.wikipedia.org/wiki/Exokernel
| Dwedit wrote:
| We even have HxDOS, which runs Win32 applications, including
| console applications. For example, even a modern version of
| 7-zip (console version) runs perfectly on ancient DOS
| computers.
| mysterydip wrote:
| Now apparently just called HX, for those (like me) looking
| for it:
| https://pmwiki.xaver.me/drdoswiki/index.php?n=Main.HX-DOS
| ale42 wrote:
| Now I just want HX running directly on UEFI! ;-)
| blueflow wrote:
| If you have UEFI you can develop against the UEFI
| interface... its a more sophisticated OS than DOS on its
| own.
| garganzol wrote:
| 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.
| justsomehnguy wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| LeoPanthera wrote:
| Today, "DOS/32" replaces DOS/4G and can even patch out the older
| runtime in binaries.
|
| https://github.com/yetmorecode/dos32a-ng
| pan69 wrote:
| I'm pretty sure you could do the same with PMODE/W back in the
| day (/W = Watcom of course). However, not 100% on the patching,
| my memory is rusty.
|
| http://www.sid6581.net/pmodew/
| Dwedit wrote:
| When you ran a game and saw "DOS/4GW Protected Mode Run-time",
| you knew you were in for a good time.
| jbverschoor wrote:
| I was so happy with my Watcom C compiler after Borland. Made me
| feel like a pro.
| Narishma wrote:
| Or a bad time if, like me, you only had a 286.
| astrodust wrote:
| Interestingly the 286 had a protected mode but very few
| applications ever used it. There were upgrade kits with then
| stupid amounts of memory, like 16MB, for then astronomical
| prices. I wonder how often those were used for anything.
| WalterBright wrote:
| I used Rational Systems' 286 DOS extender a lot. It was a
| great boon to writing programs, because it would seg fault
| on a bad pointer access.
| ElectricalUnion wrote:
| Not many I guess; the reason you basically required a
| "protected runtime" in the first place is because real mode
| (or a even better thing, the shiny new 386 virtual 8086
| mode aka virtual real mode) was very important.
|
| Until the 386, leaving the protected mode was either
| completly unsupported (I think 186) or you needed heroics
| involving bugs in the keyboard irc handler (I think 286).
| Because the OS and most "normal" applications and libraries
| back them being real-mode only, it means you were locked
| out of most of the filesystem I/O, and a program with
| limited filesystem I/O is a very limited program indeed.
| phire wrote:
| Not bugs. IBM literally wired up the keyboard controller
| to trigger the CPU's reset pin on request as a workaround
| for getting back to real mode. But not every system has
| that feature. Some motherboard chipsets had an even
| faster method for triggering reset; it was all very non-
| standard.
|
| But the most compatible way to get back to real mode on a
| 286 was by triggering a triple fault.
| rep_lodsb wrote:
| The 32-bit registers are accessible in real mode too, it only
| requires a prefix to each opcode (and the same is true when using
| the 16-bit registers in 32- or 64-bit mode). There is also no
| restriction on using the FS and GS registers in real mode, they
| work like any other segment register.
|
| There really is surprisingly little difference between real and
| protected mode, it mainly affects how segment registers are
| loaded. Internally, each segment register has a base and limit
| field that is used the same regardless of mode.
|
| Loading a segment register in real mode sets the base to the
| value shifted left by 4 bits, but leaves the limit unchanged. By
| briefly entering protected mode and loading descriptors with a
| limit of 4 GiB, it would remain that way after switching back to
| real mode, giving access to the full address space (this is
| called "flat real", "unreal", or "voodoo" mode).
___________________________________________________________________
(page generated 2023-05-11 23:01 UTC)