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 Content-Type: text/plain; charset=ISO-8859-1 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 Precedence: bulk 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.)