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: Mon, 31 May 2010 13:15:16 -0700 (PDT) Organization: http://groups.google.com Lines: 115 Message-ID: <29605d07-9686-435a-b8e3-6072967c7fc8@f13g2000vbm.googlegroups.com> References: <8d7d82d4-ce66-4b31-80a9-f6b5d7ba65ef AT o1g2000vbe DOT googlegroups DOT com> NNTP-Posting-Host: 65.13.115.246 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1275336916 9207 127.0.0.1 (31 May 2010 20:15:16 GMT) X-Complaints-To: groups-abuse AT google DOT com NNTP-Posting-Date: Mon, 31 May 2010 20:15:16 +0000 (UTC) Complaints-To: groups-abuse AT google DOT com Injection-Info: f13g2000vbm.googlegroups.com; posting-host=65.13.115.246; posting-account=p5rsXQoAAAB8KPnVlgg9E_vlm2dvVhfO User-Agent: G2/1.0 X-HTTP-UserAgent: Opera/9.80 (Windows NT 5.1; U; en) Presto/2.5.24 Version/10.53,gzip(gfe) Bytes: 5946 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Hi, On May 31, 4:01=A0am, "Rod Pemberton" wrote: > "Rugxulo" wrote in message > > news:8d7d82d4-ce66-4b31-80a9-f6b5d7ba65ef AT o1g2000vbe DOT googlegroups DOT com... > > > On May 30, 4:20 pm, "Rod Pemberton" > > wrote: > > > > I think I would've preferred a 16-bit Int 21h TSR with the functional= ity > 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). > > Compile an .exe. =A0Run exe2coff. =A0That leaves you with a "COFF executa= ble". > Delete the .exe. =A0Use go32-v2 to run the COFF executable. =A0Run stubif= y to > get your .exe back. I thought I remembered the libc having some support for executing unstubbed COFF, but I can't recall exactly. Anyways, through limited testing, it appears you can run unstubbed stuff from within Bash, but even that (apparently) relies on GO32-V2.EXE. So try that. Of course, that assumes Bash + Go32-v2 don't exceed your no-stub space savings. ;-) > > The stub is only 2 kb, so it's not big. > > True. =A0It's not that big. =A0If you don't have many DJGPP .exe files, i= t's no > big deal. =A0If you have lots of them, it does consume some additional sp= ace. > FAT allocates in chunks of various sizes, upto what 32KB (?), so that > "insignificant" 2KB can push each .exe to waste an additional larger amou= nt > of space. Strip. Disable globbing. Use -Os or -O. Use UPX. Use 2.03p2. Or build your stuff with DJELF, but that seems to even out because you can't UPX. Use DXE3. Hack the libc (e.g. _doprnt, remove unnecessary bits). Don't call libc unless you really need it, write your own routines (assembly). > Well, I was thinking about continued usage of DOS into the future, A lot of people actually want DOS to die, and a lot of companies either don't care or only care about NOT supporting it. Incompatible new-fangled hardware (AMD64, AHCI) doesn't help either. At least emulators etc. work fairly well. > like 16-bit DOS device drivers for ext2 or other filesystems, Somebody did recently write an alpha exFAT tool for DOS. (Although I don't really see the point. Stupid patents.) I think Paragon's mount tool (commercial) can handle various file systems. LTOOLS works for ext2, hence unfortunately nobody has really written a native ext2 driver for DOS. I've never seen any decent NTFS tools for DOS (either buggy or limited or slow or ...). > or like extending > Int 21h's exec functions to execute other file types, besides MZ and .com= 's. > I think these could be a benefit to DOS. =A0It'd be nice if, say, Int 21h= , was > extended to execute 32-bit code directly, perhaps with just a two letter > header to indicate 32-bit code. =A0There's no reason why Int 21h couldn't= load > MultiBoot executables like loadlin, PE binaries like HXLdr32, COFF > executables from DJGPP, or even ELF binaries. Well, I know you know that various ELF hacks have appeared over the years. So yes, it's possible. ;-) > Well, I'll list the sizes for a "hello world" file called jjj.c. =A0I've > listed bytes used and disk space used: > > jjj =A0 =A0 76933 98304 (unstubbed) > jjj.exe 78981 98304 I think you forgot to strip. > As you can see, the disk space is rounded up to a multiple of 32K. =A0Eve= ry > time the 2KB stub pushes the file size across a 32KB boundary, you get ev= en > more wasted space. =A0Yes, FAT's large allocation size is the bigger prob= lem, FAT works okay for what it's meant for, so I can't complain. However, I admit that FAT16 > 512 MB wastes too much space (16 kb clusters). It would be better to have two partitions of < 512 MB (8 kb clusters) than one big partition. One of my computers has that "problem", and it's annoying. > and the second problem may be the "fattiness" of DJGPP code as you've > indicated, but space is wasted here. =A0Albeit, space consumption wasn't = why I > brought this up, enhanced functionality of Int 21h to run other executabl= e > types was. =A0We both know OpenWatcom produces much, much leaner > executables which can help save space. Yes, but they only recently got LFN support for DOS (in soon-to-be- finalized 1.9, currently at rc6). Besides, they don't worry about POSIX compatibility or porting GNU stuff. I don't mean to pick on DJGPP (as some other compilers / runtimes are much much bigger), but yeah it could be somewhat slimmed. I've only briefly dabbled into looking at how (as vaguely mentioned).