Mail Archives: djgpp/1994/07/12/10:23:45
> However, I thought it was decided a while back that this would
> not work because the area where the !proxy information is kept
> (for passing parms from stub to go32) and the method that go32
> uses to pass parms to other go32 programs (is this !proxy as
> well?) would get swapped out as well, and therefore overwritten
> when the new program is loaded.
Oh, there is that also. I guess a custom one for go32 would be needed
for that.
> The only way I could think of fixing this problem would be to
> lose the !proxy method of passing parms, and use the LONGARGS
> method that Thorsten developed for the gnuish project. Go32
> currently supports the LONGARGS method for *receiving* parms, so
> it should be doable to comment out the !proxy code in stub and
> go32, and just drop in Thorsten's swaplib code.
The proxy code is the shortest way for stub to run, and it passes more
than just the arguments that way. It also passes the stubinfo data.
> Actually, I'm not sure how much of a non problem it really is.
> If I read DJ's comments correctly, if one tries to run multiple
> DPMI processes under QDPMI, it still requires about 105k of DOS
> memory per program... so after a few recursive makes, and gcc
> calling cc1 and so on.. you're still running tight on memory.
> (Although it appears that windows is more effecient, and you only
> use up 9k of DOS memory per process). Or did I misread
> something? Hopefully, if a free DPMI server is created, it does
> a much better job than QDPMI!!
The DPMI buffer wouldn't be swapped out anyway (or would it?) as it's
a different memory region than the rest of the program. I don't know
what would happen on DPMI if that wasn't present when an interrupt
happened (DPMI allows clients to have 32-bit interrupt handlers, even
when they shell out to a 16-bit program).
- Raw text -