X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: "neozeed (neozeed AT superglobalmegacorp DOT com) [via djgpp AT delorie DOT com]" Newsgroups: comp.os.msdos.djgpp Subject: Re: Death of DJGPP support on Win10 32 bit? [WAS: Re: Max value of DpmiLimit registry setting in Windows 10 32 bit] Date: Sat, 14 Apr 2018 18:30:45 +0800 Organization: Qemu OS/2 Lines: 33 Message-ID: <20180414-103045.802.0@neozeed.news.eternal-september.org> References: <83sh8c47ey DOT fsf AT gnu DOT org> <83r2nw44a6 DOT fsf AT gnu DOT org> <20180406-091036 DOT 863 DOT 0 AT neozeed DOT news DOT eternal-september DOT org> Mime-Version: 1.0 Content-Type: Text/Plain; charset=US-ASCII Content-Transfer-Encoding: 7Bit Injection-Info: reader02.eternal-september.org; posting-host="7e40678a69ac4c40bcbab31600a2cde7"; logging-data="4855"; mail-complaints-to="abuse AT eternal-september DOT org"; posting-account="U2FsdGVkX18E7sNbSnGMONuC744Z7wLS" X-Newsreader: WinVN 0.99.16.0 (x86 64bit) Cancel-Lock: sha1:PvcQScAh1AOYMXJzGDlAyNOyQD4= Bytes: 2778 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com In article , rugxulo AT gmail DOT com says... >Hi, > >On Friday, April 6, 2018 at 4:10:41 AM UTC-5, neozeed wrote: >> >> If the NTVDM can't nest properly, isn't it easier to just use >> a Win32 native version of GCC, and keep your CC1/CPP/GAS/LD native? > >(I think I misunderstood this comment the first few times that I read it.) > >So you're saying use a Win32 (PE/COFF) gcc.exe as frontend with other >.EXEs remaining DJGPP (DOS, MZ/COFF)? > >IIRC, that's what they did back in the old days when certain OSes >(OS/2?) had similar problems. E.g. /deleted/v1gnu/gcc263rm.zip >says "gcc-2.6.3 gcc.exe built with tcc, for djgpp". (Okay, not Win32 >but 16-bit DOS, still a similar workaround.) > >But I don't think that will help us much here because all DJGPP >.EXEs do some proxy stuff to transparently handle really long cmdlines >(beyond normal DOS limits). > >So it's probably not immediately compatible, but I don't fully >understand all of the details. Yes, a million years ago the GCC.EXE driver was a turbo C++ exe for issues with nesting. Although regarding the issues with long filenames, if the CPP is native, doesn't that remove that barrier? After that it's just the temporary files, which should (hopefully) be 8.3 friendly, or something that gcc.c can be forced to use friendlier temporary names, so that CC1/GAS/LD can happily continue.