Closed stsp closed 1 year ago
Yup, same as cwsdpmi.
To align to an arbitrary boundary, there is .balign.
OK, lets say its too difficult to port the stub to gas. :) djasm also links the file and produces the full-blown realmode executable in one go. With gas I can only create the stub itself and if I link it with ld, then it will add its own stub... So the best I can do is to try ia16-ld, but then its not any better than djasm.
Or maybe @tkchia will upstream his new linker target? :)
Yup, same as cwsdpmi.
So do you rename hdpmi into cwsdpmi? How does this stub ever execute hdpmi?
Renaming is one option, or you can use stubedit
to set the dpmi host.
In that case I would suggest to add the proper hdpmi support, so that the stub try to execute it before trying cwsdpmi. And ignore the retcode only for hdpmi case. I do not think you can present the situation where you edited the stub, as a bug that needs fixing. Or you can use some env var for specifying DPMI host, and have a retcode quirk if the host is set to be hdpmi. Of course since I am not even subscribed to djgpp list, my opinion about any patches there, can be ignored.
Adding such specific workarounds would significantly increase the stub size. The patch I submitted is a more universal solution, and it even saves a few bytes.
Even better would be to make hdpmi32 just return 0 on success. I did raise the issue with Japheth, but he doesn't remember what the purpose of the exit status was - so I don't know yet if anything would break if it were changed.
Not a specific work-arounds, but rather a support for other DPMI hosts. If various hosts are supported, then you could claim a bug is there because hdpmi is not working right. Currently its just not a bug. I think having a variable to define a DPMI server would be good, and use cwsdpmi as a fall-back. Then how to fix that particular problem with hdpmi (which currently doesn't exist!) should be thought again. Maybe for example ignore retcode from any non-default DPMI server (the one specified via an env).
The stub already supports loading "non-standard" dpmi hosts - you can set it via stubedit
. How is that different from using an environment var?
Indeed, they seem to prefer the use of stubedit for specifying many things, instead of using env vars...
Hi!
https://github.com/stsp/djstub I pushed the initial version of a new stub that is free from djasm. Its fully functional as far as I can tell, though my "test-suite" is not that big. But I do not suppose you are going to be interested in that work. In fact, I am secretly trying to re-implement the entire toolchain, and this is just the first component that works already. Others will follow... sometime. Or not. :)
Hi.
I wasn't yet successful in creating PE executable with raw binutils (rather than with djgpp), but, unless I am mistaken, ld still embeds the old stub (the one w/o my patches). Only stubify tool has the new stub, so when using djgpp, the stub is good. But I believe creating PE with raw binutils will yield the old stub. I looked into an ld binary and I can see the old stub there because the error msg that I added, is not there.
How does ld embed the PE stub? Is it hard-coded somewhere in the sources? I mean, the one doesn't build djgpp libc when building the raw binutils. But the stub is there.