X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
X-Received:	by 10.224.215.194 with SMTP id hf2mr33386032qab.0.1368997221745;
	Sun, 19 May 2013 14:00:21 -0700 (PDT)
X-Received:	by 10.49.106.231 with SMTP id gx7mr4063980qeb.6.1368997221723;
	Sun, 19 May 2013 14:00:21 -0700 (PDT)
Newsgroups:	comp.os.msdos.djgpp
Date:	Sun, 19 May 2013 14:00:21 -0700 (PDT)
In-Reply-To:	<231bd669-af0b-4000-b7f0-7d26ab6b9664@googlegroups.com>
Complaints-To:	groups-abuse AT google DOT com
Injection-Info:	glegroupsg2000goo.googlegroups.com; posting-host=65.13.115.246;
	posting-account=p5rsXQoAAAB8KPnVlgg9E_vlm2dvVhfO
NNTP-Posting-Host:	65.13.115.246
References:	<231bd669-af0b-4000-b7f0-7d26ab6b9664 AT googlegroups DOT com>
User-Agent:	G2/1.0
MIME-Version:	1.0
Message-ID:	<7b35d915-e8ea-484d-b541-e5cba7a5ee52@googlegroups.com>
Subject:	Re: to delorie
From:	rugxulo AT gmail DOT com
Injection-Date:	Sun, 19 May 2013 21:00:21 +0000
Bytes:	9601
Lines:	180
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

Hi,

On Sunday, May 19, 2013 1:06:22 AM UTC-5, Jim Michaels wrote:
> 
> I get the following message from windows 7 64-bit.
> 
> "Unsupported 16-bit Application:
> 
> this is because it is not 32-bit and therefore does not come
> with command.com and therefore cannot run 16-bit dos apps like
> the current DJGPP compiler.

Command.com is the shell. While you still need it (as apparently CMD
may still call it behind the scenes), the main part of NTVDM is
elsewhere, e.g.  DOSX.

And yes, most of us have known about this for years. Win64 doesn't run
DOS apps. (Dunno why, supposedly a 486 emulator existed for non-x86 NT
versions back in the day, but I guess it bitrotted to death.) MS isn't
too nostalgic regarding DOS. They prefer their own newer Win32 stuff.

Though DJGPP isn't 16-bit, but it relies on 16-bit calls to DOS and
BIOS.  If DOSEMU can run under x64 under Linux (faking all those
calls), it's technically possible for Windows too, but nobody has
bothered. (Try VirtualBox with latest VT-X running FreeDOS, it's much
less painful than otherwise.)

There were some hybrid environments in the past, e.g. RSX (1999) or
EMX (2001) or Borland (32RTM circa 1993?). You can also run some Win32
(esp. OpenWatcom-based) stuff under DOS with HX.

> windows 8 and windows 8.1 do not come with (to my knowledge)
> an XP mode like windows 7 does. xp mode is a 32-bit windows
> XP emulator that runs under Microsoft Virtual PC.

I hate to be a cynic, but that was all a marketing gimmick to appease
the Vista haters. Now that Win7 is fairly well established, there's no
need for such a thing. (It was only explicitly to help businesses
migrate anyways, and it easily doubled your RAM and HD footprint.)

> 64-bit boxes are all that's available now. please make your tools
> hostable on 64-bit windows.

It's been done, at least unofficially. I don't have any reliable
builds myself, but I always hear of others doing it. But GCC is always
less supported on Windows than Linux. You could try Cygwin, but I
question the value of cross-compiling atop Windows (in some
situations).

I'm not saying cross-compiling isn't useful, many have done it (e.g.
YASM, Hammer of Thyrion, NASM, etc), but outside of just providing
latest snapshots, it doesn't solve the need for testing and debugging.
(And keep in mind, OpenWatcom has supported cross-compiling "out of
the box" for years.)

Most DJGPP cross-compilers that I know of are *nix-hosted. At least on
Linux you can run DOSEMU. On Windows, DOSBox can run some stuff too
(though not compiler!), but it's really "only for games", so it's not
perfect (esp. due to its fake DOS and hard limit on 64 MB RAM
maximum).

> I have never tried this on a 64-bit version of windows before. but
> this is what you get.

Unlikely to ever be resolved. While there is (last I heard) a 32-bit
edition of Win8, that's probably the final straw. I know some people
think you need Windows to comfortably run DJGPP, but I consider it
(using Windows for DOS) a lost cause at this point. I'd rather use
DOSEMU or VirtualBox, honestly.

EDIT: (quoting Wikipedia) "The three desktop editions of Windows 8 are
sold in two sub-editions: 32-bit and 64-bit. The 32-bit sub-edition
runs on CPUs compatible with x86 architecture 3rd generation (known as
IA-32) or newer, and can run 32-bit and 16-bit applications, although
16-bit support must be enabled first."

> do you intend to come out with a windows 64-bit hosted compiler
> targeting 32-bit DOS i386?

Anything's possible, but I've not seen any plans, and there aren't
enough volunteers (outside of Juan the miracle worker and a few
others, heh). GCC "should" (famous last words) build a cross compiler
very easily, but you may need "latest DJGPP patches" for latest GCC.

I can already hear people saying, "What would be the point? Do you
need more than 2 GB to compile?" So there's no huge advantage. In
fact, a Win32-hosted, not 64-bit hosted, version would be more widely
useful.

> do you intend to support more target memory than 16MB somehow?
> (such as 2-4GB at least?)

Depending on your machine and setup, you can already use approx. 2 GB
or maybe more. I know I've done it. Heck, latest GCC -O2 isn't exactly
frugal.

I don't know where you got 16 MB from. That was only a limit for 286s,
and DJGPP has never been less than 386. That ship has long ago sailed.
(Though it could be argued that we use too much RAM these days, but
anyways ....)
 
> I hear windows 8 and windows 8.1 have some sort of virtual machine
> technology that's supposed to be ahead of microsoft virtual pc.

Hyper-V? Only in 64-bit editions, requires EPT (nested pages?) or
whatever, which means you have to have latest VT-X extensions, which
not all cpus provide. Haven't tested it, don't care to. Maybe MS
considered that a suitable replacement, dunno, but it's unlikely to
solve everyone's problems.

> but I am afraid that command.com is no longer since windows 8 only
> runs on 64-bit boxes to my understanding - it requires PAE (address
> extensions), the NX bit, and some other things to be enabled.

I'm pretty sure I heard there was a 32-bit edition. But yeah, it
requires later-edition P4s or newer due to PAE. Not sure why that was
considered a good idea to target less cpus, but whatever, I guess for
most machines it's not a big deal (and "older" OSes like Win7 are
still available for purchase, though XP will probably fade away fairly
soon, sadly).

> I know that UEFI has deprecated BIOS calls + MBR in favor of UEFI.

Everybody deprecates everyone else. It's a constant war to declare the
opposition "dead" or "obsolete". Quite annoying, honestly, but
everybody wants control and very few care about compatibility. Legacy
is a dirty word.

> would you be interested in coming out with a UEFI+GPT-based
> compiler? I know the freedos folks are looking for a compiler
> which could target both UEFI and BIOS calls, but still be DOS-ish.

You mean hosted atop the UEFI shell or whatnot? Uh, unlikely. And I
don't think anybody at FreeDOS explicitly expects or wants any of it.
Most people don't care as much for all the newest stuff (or only use
so-called "modern" software on modern machines). UEFI is far beyond
their radar (and mine), AFAICT.

> basically it is asking for dos to continue without the need for
> virtual machines.

Unlikely. Most people aren't fans of DOS and have no sense of
minimalism. At best, you're only likely to find a vaguely similar
mindset in FreeBSD, which doesn't install X11 by default. Console
stuff is still availble, but a lot of people consider that inferior,
deprecated, whatever in lieu of GUI.

Virtual machines, when they work, are as good as we can expect these
days (outside of running on native hardware, natch). VT-X helps a lot,
I can't stress that enough.

> freedos currently uses FAT32, and there is support for long
> filenames with the appropriate driver (still have not gotten that
> to work yet).

Shouldn't be hard. Use latest version of DOSLFN (IIRC, 0.41c). Make
sure you first unzip all your DJGPP .ZIPs with it loaded!

> I have a nice utility I spent years building in DOS I didn't want to
> lose. and I have a lot of others I have ported to DOS, and wouldn't
> mind porting again if I could have a cd-romable OS that will work
> with a 64-bit box fine.

I don't personally see any huge advantage in 64-bit, but it's already
gotten a lot of attention, so we're kinda stuck with it (even for
non-server home use, ugh). Unless your app needs more than 2 (or 4)
GB, it's not very useful.

In other words, no reason to port/update anything if it still works.
At least for now, we still have BIOS and 16-bit cpu compatibility, so
just use it "as is" and worry about the future later. Like I said,
everything changes so fast and everyone has different ideas, so we may
have entirely incompatible hardware in the future (as we're seeing
with all these ARM cpus). At least we have emulators, even if they
aren't perfect, better than nothing.

If you're worried about code and wanting it to last through the near
future, the only answer is strict portability, e.g. stick to ISO C99
and/or POSIX or similar. (While I'm no huge fan of POSIX, others are,
and hence it's fairly well-supported across modern platforms. Not
necessarily ideal, but again, it's better than nothing.)

- Raw text -