Re: Win32Forth command-line apps
- From: Rugxulo <rugxulo@xxxxxxxxx>
- Date: Sat, 14 Nov 2009 09:41:03 -0800 (PST)
Hi,
On Nov 14, 10:25 am, "Ed" <nos...@xxxxxxxxxxx> wrote:
Rugxulo wrote:
Okay, this might be almost offtopic, but "why?" exactly?
I'm guessing it's due to 64-bit Windows being unfriendlyto 16-bit.
I didn't enquire but I assume it was for future-proofing.
With each new Windows version, support for DOS has reduced
e.g. Vista won't run any graphics DOS app.
They changed the driver model in Vista, so it broke some stuff. In
fact, as you probably know, Vista had a lot of compatibility issues,
even with Win32 stuff. I would heavily doubt Win7 is any better as
it's based upon the same kernel (Vista = NT 6, Win7 = NT 6.1).
As technology changes
supporting old systems becomes harder and more expensive.
I've been told that NTVDM is "ancient". However, that still doesn't
explain the shift from "works" (XP) to "barely works" (Vista).
Something odd happened, and I don't know what or why. (Compiler
bugs??)
One can understand MS not wanting to do that considering
the average computer user today wouldn't know the difference
between a program and a data file.
No, I honestly can't. I'm not going to give a big anti-MS rant as is
found everywhere else on the 'Net [EDIT: eh??? oops, heh], but I do
have issues with their attitude. Anybody who has run DOSBox or
VirtualBox knows that such things are still way too slow. V86 mode
exists for a reason, might as well use it. (Bill Gates called the 286
"braindead" for its pmode-only attitude. Hence V86 was a big
improvement, some say directly a result of MS petitioning for it. I
guess AMD didn't get the memo?)
What actually boggles my mind is that MS has always had trouble with
NTVDM. For instance, the original Quake (DOS/DJGPP) couldn't run under
NT due to bugs that MS either couldn't or refused to fix. And that was
a big-time game! If they didn't fix it for them (the Doom guys!),
something is wrong.
Then when Win2k/XP finally got prevalent, there were other bugs that
prevented DJGPP apps from working (hence DJGPP 2.03's patchlevel2).
Again, not fixed by Microsoft.
However, Win2k did actually add LFN support to DOS apps (previously
only available in Win9x), and WinXP added SB emulation. WinXP was the
only one of those to be offered to home users, and it was the
successor of WinME. Hence, they (I guess?) wanted to attract the DOS
(business?) users. And then they declared "DOS dead".
But Vista broke full-screen (even cmdline apps attempting simple VESA
identification calls) due to a new driver model. Allegedly you can
unofficially use an XP driver (if you can find one), but that disables
Aero, which some other apps need. Not good.
And here's the worst part: Win2k3. For some reason, somebody silently
added a 32 MB limit to any DPMI app without telling anyone, and
apparently nobody else noticed or cared. When Vista came out a few
years later, it still wasn't fixed. Only with SP1 (a year later) did
they add a (heavily undocumented!) registry hack, but Win2k3 doesn't
even support that, and no more SPs for Win2k3, even. What gives?? My
laptop (circa late 2007) "only" has 1 GB of RAM, and it's a 32-bit
Windows. 32 MB is 3% of my total RAM. If you think that's a reasonable
amount, then you don't do enough compiling with DJGPP. And that's
static no matter how much total RAM you have! I don't know who thought
that was a good idea. But apparently it's not worth fixing. Again.
That's (I think) worse than Win 3.0, even, which was the first to
support DPMI (0.9 only, sadly). Even DOSBox supports more total RAM,
64 MB. (But you need 1+ Ghz for "486" speeds!) Did I mention that DPMI
is almost the only way for DOS apps to access more RAM under Windows?
So you're effectively locked out.
Did I mention that MS doesn't support NTVDM under Win64? I know x86-64
doesn't support V86, but they did at one time emulate DOS apps on non-
x86 platforms. I guess I can't majorly complain there as we have
DOSBox, VirtualBox, (or DOSEMU under Linux w/ 16-bit emulation) etc.
But those are (again) not solutions provided by MS. (XP Mode doesn't
count either as home versions of Win7 aren't officially supported.
Besides, that needs an *extra* 1 GB of RAM, extra 16 GB of space, and
hardware virtualization support.)
P.S. Yeah yeah, nobody cares, I'm a loon, costs too much, blah blah
blah, Win32 API kiss kiss, DOS is old ptui yuck, .NET is the future or
use Linux, etc. Yeah, it's so much fun to throw away working software
and recompile / port everything over and over and over ....
.
- References:
- Win32Forth command-line apps
- From: Ed
- Re: Win32Forth command-line apps
- From: Rugxulo
- Re: Win32Forth command-line apps
- From: Ed
- Win32Forth command-line apps
- Prev by Date: Re: Win32Forth command-line apps
- Next by Date: Re: I was concerned about google writing an OS - Now I see the funny side
- Previous by thread: Re: Win32Forth command-line apps
- Next by thread: Re: Win32Forth command-line apps
- Index(es):
Relevant Pages
|
