From: mcastle AT cs DOT umr DOT edu
Subject: go32 in commercial products (was Re:  Packing go32 into an .exe)
To: peprbv AT cfa0 DOT harvard DOT edu (Bob Babcock)
Date: Thu, 31 Dec 92 0:04:51 CST
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu

> 
> >>copy /b stub.exe+prog prog.exe
> >>...
> >>copy /b go32.exe+prog prog.exe 
> >>...
> >>The latter method requires royalties to be paid when you sell the
> >>.exe to someone else.
> 
> Does this mean that if I were to use djgpp in a commercial product, I would
> have the options of
>    1. Use copy/b or equivalent to combine the files and pay royalties
> or 2. Have my customer do this operation as part of the installation and
>       not pay royalties?
> Does this make sense?

No, you could use aout2exe to prepend stub.exe to the a.out file, and provide
go32.exe as a separate executable.  Then also either ship the source for go32
with the product, or make arrangements to provide it upon request.  This would
not be the only products that ship the the dos-extender as a separate entity.
I believe DV/X comes with a separate extender (dos4gx or something), correct?
So anyway, keeping go32.exe separate from the runtime code is not unheard of.

> 
> (I haven't done anything with djgpp since around version 1.04.  At that time,
> djgpp gave me a 4x performance boost in a time-consuming sort, but did not
> support some DOS interrupts which I need to use and did not allow recovery
> when a memory allocation failed because the swap disk was full.  My
> understanding from messages on this list is that the later is still true, and
> it just isn't acceptable in commercial software.)
> 

True, but how many commercial products do you know would allow access to their
source so that if you really wanted to provide interrupt handling and error
recovery, you could?  This is the whole behind free software.


Actually, part 2 above would still not be all that difficult.  I imagine you
could easily write and install program that would do the combining without
the user even really noticing.  

I imagine this same approach could be used to solve the problem of using fsf
library code.  You ship you product as .o files, and the fsf libraries and
source.  Then your install program simply links them together.  Sure, makes
installation a bit slower, but this way your (more advanced) customers will
be able to improve fsf code or link in others improved code, without having
to have access to your code.  I'm not sure on this point, but if you supply
the fsf code like this, you don't have to pay royalties, correct?

disclaimer: some of this information may be completely off base.  feel free 
			to correct any errors.

regards,
mrc