You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the direct elf loading is
"too direct". It bypasses stub and
all 32bit initialization. It shares
the dj64 handle with comcom64,
and therefore can't be done from
comcom32...
This is a very unportable design.
Explore the possibillilty of full
initialization and a comcom32
port. In case of comcom64, this
will likely mean multiple dj64
clients within a single DPMI client.
The text was updated successfully, but these errors were encountered:
Likely not worth a trouble.
If we create a new stubinfo, there
would likely be leaks on exit, including
the leak of a DOS memory region.
Calls to 0x4c should be hooked and
replaced with cleanups.
If we share the stub, then its not
possible to relocate the 32bit code
to a new address.
The current technique seems to work
in most cases, and who cares about
comcom32 or ET_DYN abuses?
Currently the direct elf loading is
"too direct". It bypasses stub and
all 32bit initialization. It shares
the dj64 handle with comcom64,
and therefore can't be done from
comcom32...
This is a very unportable design.
Explore the possibillilty of full
initialization and a comcom32
port. In case of comcom64, this
will likely mean multiple dj64
clients within a single DPMI client.
The text was updated successfully, but these errors were encountered: