convert __dpmi_int() to inline asm

[stsp]

... to get rid of go32 stuff.

[ecm-pushbx]

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

[stsp]

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

[ecm-pushbx]

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.

[stsp]

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.

[ecm-pushbx]

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).

[stsp]

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.

[stsp]

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.

[ecm-pushbx]

Maybe dosmemput or dosmemget would be more portable than movedata?

[stsp]

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.