X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: Rugxulo Newsgroups: comp.os.msdos.djgpp Subject: Re: TSR of go32-v2.exe or TSR for unstubbed COFF executable loader available? Date: Sun, 30 May 2010 19:08:47 -0700 (PDT) Organization: http://groups.google.com Lines: 43 Message-ID: <8d7d82d4-ce66-4b31-80a9-f6b5d7ba65ef@o1g2000vbe.googlegroups.com> References: NNTP-Posting-Host: 68.220.172.161 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1275271728 18153 127.0.0.1 (31 May 2010 02:08:48 GMT) X-Complaints-To: groups-abuse AT google DOT com NNTP-Posting-Date: Mon, 31 May 2010 02:08:48 +0000 (UTC) Complaints-To: groups-abuse AT google DOT com Injection-Info: o1g2000vbe.googlegroups.com; posting-host=68.220.172.161; posting-account=p5rsXQoAAAB8KPnVlgg9E_vlm2dvVhfO User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 ( .NET CLR 3.5.30729),gzip(gfe) Bytes: 2939 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Hi, On May 30, 4:20=A0pm, "Rod Pemberton" wrote: > > "HXLdr32: this is a TSR program which will hook DOS interrupt 21h and > check all programs to be launched if they are PE binaries. If this is tru= e, > DPMILD32 will be started to run the program. > > I think I would've preferred a 16-bit Int 21h TSR with the functionality = of > DJGPP's go32-v2.exe to load and run unstubbed COFF executables over > stubbed COFF... I think (??) go32-v2.exe doesn't do much unless you want to run v2 and v1 binaries under each other (rare). It even still relies on CWSDPMI, I think, so it wouldn't help anyways, you'd still need DPMI. (I think DPMILD16/DPMILD32 do mostly the same stuff as HDPMI16/HDPMI32.) In short, I never use it. The stub is only 2 kb, so it's not big. It's not wasting much space. The built-in default globbing alone is like 6 kb, and printf (or _doprnt, honestly) isn't exactly optimal either. Oh, and mkdir using xstat bringing in ctime unnecessarily (12 kb unstripped) is a bigger issue (as I found out a year ago). GCC -Os could be much smaller output too. However, long story short, nobody has time to fix all that, and nobody cares. "HDs are cheap enough." (Ugh, I dare the next person who says that to create a permanent 1 GB file saying it 100000x without getting annoyed.) I'm not at home, so my compiler choices are limited, but here's what GCC 3.4.4, DJGPP 2.03p2 results in: #include int main() { return 0; } gcc -s -Os -march=3Di386 test.c -o test.exe -rwxr-xr-x 1 Owner root 43520 May 30 20:53 test.exe So the tiny stub is the least of (y)our problems. Check the map file to see where it all goes. ;-)