Mail Archives: djgpp/2010/05/31/16:30:09
Hi,
On May 31, 4:01=A0am, "Rod Pemberton" <do_not_h DOT DOT DOT AT notreplytome DOT cmm>
wrote:
> "Rugxulo" <rugx DOT DOT DOT AT gmail DOT com> wrote in message
>
> news:8d7d82d4-ce66-4b31-80a9-f6b5d7ba65ef AT o1g2000vbe DOT googlegroups DOT com...
>
> > On May 30, 4:20 pm, "Rod Pemberton" <do_not_h DOT DOT DOT AT notreplytome DOT cmm>
> > 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).
- Raw text -