Date: Wed, 31 Aug 94 11:32:11 -0400
From: dj AT ctron DOT com (DJ Delorie)
To: OKRA AT max DOT tiac DOT net
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: TSRs?

>   Is there some way to get my program started and then tell go32 it's no 
> longer needed?  I promise not to use go32 functions. ;)  No, go32 does 
> interrupt stuff, right?  So I suppose it wouldn't be easy to just get rid 
> of it... In DJGPP version 2, there won't be a go32 so would it then be 
> okay to make TSRs?  

go32 knows about your memory allocations and will free them when it
exits.  There's probably other things it does also, like cleaning up
interrupt vectors.  In general, it just wasn't designed for TSRs.

>   BTW: how exactly are you going to get rid of go32?  what about all the

By relying on DPMI and using _go32_dpmi_simulate_interupt exclusively.

> programs that use the go32_* functions?  Will my executables grow by 70k

The _go32_* functions will still work.  In fact, the V2.0 library is
almost completely backwards compatible with the V1.X library,
including int86() functionality.  We copied some parts of go32 itself
into libc.a.

> by just sticking the go32 stuff into my program?  I assume once you've

The smallest program is 24K (still).  Go32 is big, but the extra
support in libc.a isn't that big at all.

> eliminated go32, it would be quite a bit harder to make a communal go32
> that all DJGPP programs could use...  What's the point of getting rid of
> go32?  Right now I can distribute say five little programs and a copy of

go32 requires a commmercial non-GPL compiler to build.  The purpose is
to make it completely self-sufficient.

> go32 for them all to use.  If you stick it in each program, my little
> bundle will be quite a bit bigger I would think.  Or are you only going to

Not much bigger.

> include the parts of go32 that the program actually uses?  If there's no

Yes, the library will only link in the functions that you need.

> go32, how are you going to debug your programs?  How long do you think

Hopefully, with gdb, if I can ever find the time to make it work with
V2.0.

> it'll be before version 2 comes along?  After 1.12, 1.13, 1.20, 1.50?  I
> could think of a million more questions, but that's enough for now. :)

I think the best thing to do is to get 1.12 stabilized (1.12.m#) and
call it 1.13 without changing anything, so that we have a release that
doesn't need maint releases.  V2.0 works, it's just not ready for
release yet.