convert __dpmi_int() to inline asm about comcom64 HOT 9 CLOSED

Why? http://www.delorie.com/djgpp/doc/libc/libc_246.html says that __dpmi_int is in dpmi.h, not go32.

from comcom64.

dpmi.h is also not very portable.
Why have you included go32.h?

from comcom64.

Did I add it? I think _my_ds() or _dos_ds is defined there. Which I use for movedata calls.

I don't understand how inline-assembly would be more portable. You can write a wrapper that implements __dpmi_int with an inline-assembly call (either to the interrupt or, as DJGPP does, to Int31.0300). If you use inline-assembly in the application that's fixed and non-portable.

from comcom64.

Please see here an example:
https://github.com/stsp/comcom32/blob/master/command.c#L256
where I converted __dpmi_int()s added by @andrewbird
Its not difficult at all, I can do that myself later.
You don't need to call Int31.0300 at all.

from comcom64.

You have to call 31.0300 though if parameters to the function or results are passed in segment registers. That's the case fot Int21.49 and .4A in my LOADFIX implementation. It might be possible to call directly if there is a DOS extender but a. we don't want to depend on extenders and b. the call semantics will vary (eg 21.49 will expect a selector returned by 21.48, which cannot be directly compared to a segment value as I do).

from comcom64.

You have to call 31.0300 though if parameters to the function or results are passed in segment registers.
That's the case fot Int21.49 and .4A in my LOADFIX implementation.

int2f/ae00 in the example above, expects the segment in DS, too.
http://www.ctyme.com/intr/rb-5189.htm
This is not a problem.

we don't want to depend on extenders

In the general case - yes.
But comcom32 is not supposed to be generic.
Its dosemu-specific.
When it is ported to 64bit, there will probably be no
use for the 32bit version, so it will likely die. Unless
you need it for something else.

eg 21.49 will expect a selector returned by 21.48, which cannot be directly compared to a segment
value as I do

Yes, I see, you should still use a DPMI call to get the
seg base then... :( Lets defer this to the actual port then,
to see what can be done.

from comcom64.

And also calling 21h/48h directly, as I suggested,
doesn't even go to DOS, but is rather calling a DPMI malloc.
So indeed, LOADFIX is special and can't work with the
inline asm instead of a DPMI calls. I wonder how will I
port that, and the movedata() stuff is also quite port-unfriendly
because of the direct use of the non-flat selectors.
We seem to pollute the sources quite rapidly. It was very
portable initially, but almost every patch I applied within the
comcom32 project, pushes the portability away.

from comcom64.

Maybe dosmemput or dosmemget would be more portable than movedata?

from comcom64.

Yes, in case of _my_ds() that looks like a much better
choice. Unfortunately some code (added by me) uses
movedata() with other selectors. But if you convert at
least the _my_ds() cases, that would be good.

from comcom64.