Mail Archives: djgpp/2010/05/31/05:15:05.1
"Rugxulo" <rugxulo 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 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).
Compile an .exe. Run exe2coff. That leaves you with a "COFF executable".
Delete the .exe. Use go32-v2 to run the COFF executable. Run stubify to
get your .exe back.
> It even still relies on CWSDPMI,
> I think, so it wouldn't help anyways, you'd still need DPMI.
True. You still need a DPMI host, but the TSR could load or unload it as
needed. Or, IIRC, you could load the DJGPP DPMI hosts as a TSRs, but that'd
be less desirable, IMO.
> The stub is only 2 kb, so it's not big.
True. It's not that big. If you don't have many DJGPP .exe files, it's no
big deal. If you have lots of them, it does consume some additional space.
FAT allocates in chunks of various sizes, upto what 32KB (?), so that
"insignificant" 2KB can push each .exe to waste an additional larger amount
of space.
> However, long story short, nobody has time to fix all
> that, and nobody cares.
Well, I was thinking about continued usage of DOS into the future, like
16-bit DOS device drivers for ext2 or other filesystems, 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. It'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. There'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. It's probably really a topic
for comp.os.msdos.programmer or some FreeDOS or DR-DOS forum... So, I just
asked why it hadn't been done that way. Given the "obviousness" of it from
Japheth's elegant description, ISTM that the DJGPP team must of considered
running COFF executables directly by extending Int 21h. They might've even
done so originally.
> 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 <stdio.h>
> int main() { return 0; }
>
> gcc -s -Os -march=i386 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. ;-)
Well, I'll list the sizes for a "hello world" file called jjj.c. I've
listed bytes used and disk space used:
jjj 76933 98304 (unstubbed)
jjj.exe 78981 98304
As you can see, the disk space is rounded up to a multiple of 32K. Every
time the 2KB stub pushes the file size across a 32KB boundary, you get even
more wasted space. Yes, FAT's large allocation size is the bigger problem,
and the second problem may be the "fattiness" of DJGPP code as you've
indicated, but space is wasted here. Albeit, space consumption wasn't why I
brought this up, enhanced functionality of Int 21h to run other executable
types was. We both know OpenWatcom produces much, much leaner executables
which can help save space.
Rod Pemberton
- Raw text -