adjusting cstrt386.asm for HX

[Baron-von-Riedesel]

Hello,

I'm currently trying to adjust cstrt386.asm for the hx dos extender to make it run with OW v2. I did this for v1.9 and that version works.
For OW v2, the modifications are done insofar as the program starts and exits without crash. However, memory allocation doesn't work yet. What variables except _curbrk have to be setup in v2.0?

Edit: it seems to depend on the "extender type" that is set. If I set X_RATIONAL, memory allocation works. First I selected the new X_HX setting, which causes the problem. Therefore I guess memory allocation for flat model may somehow depend on the DS segment limit?

[jmalak]

I'm not familiar with the HX extender, but I've looked into this idea of adding support for it to OW in the past.
All depends on how specific the HX extender is against DOS4GW.
The OW code (C runtime library) for the DOS4GW Extender mostly uses the 32-bit DPMI API. If "extender type" X_RATIONALE is used for HX, the programs could work with HX. I think if any code in C run-time library is DOS4GW specific then it could be replaced by DPMI call to be portable to HX. May be that we could add a new "extender type" for the HX extender so that we can modify the code anywhere for HX without broken DOS4GW specific code. Next possibility is to replace such code by DPMI API call if possible.
But some OW code in sampler and trap module is 16bit mode code which uses access to 16bit DOS4GW API functions which precludes using such code for HX extender.
This is not a problem as such code must be specific to the HX extender anyway. Extra code, similar to other extenders.

Anyway if you have code for OW 1.9 then it should work with OW 2.0 because there should not be big difference in C run-time library. OW 2.0 CRTL is mostly extended for better POSIX support. If there are some problems then it should be reported to be fixed or changed.

[Baron-von-Riedesel]

If "extender type" X_RATIONALE is used for HX, the programs could work with HX.

Yes, that works ( mostly, IIRC the "spawn" family of functions have problems ). I just wonder what the new "extender type" X_HX is good for.

Anyway if you have code for OW 1.9 then it should work with OW 2.0 because there should not be big difference...

That's true. It's more a technical problem: if new externals are added to cstrt386.asm, those have to be added to the modified code as well.

[jmalak]

If "extender type" X_RATIONALE is used for HX, the programs could work with HX.

Yes, that works ( mostly, IIRC the "spawn" family of functions have problems ). I just wonder what the new "extender type" X_HX is good for.

X_HX it was done in the past if I was thinking about adding HX DOS extender to supported Extenders.
It is only declaration of new type but not setup by startup code. To be usable it needs to add detection code for HX to startup code.
After that it can be used in code, now it is not used anywhere in OW code.

Anyway if you have code for OW 1.9 then it should work with OW 2.0 because there should not be big difference...

That's true. It's more a technical problem: if new externals are added to cstrt386.asm, those have to be added to the modified code as well.

It is not problem to implement it into OW2.0 code that it will be maintained by OW developers if such situation appears.
I think it will be a few parts of code nothing big.

[Baron-von-Riedesel]

I played around with OW2.0 and some 32.bit DOS applications created using HX - works very well.

There's a little mystery, though: I've made a special PE loader that changes the page attribute of non-writeable section to R/O ( with DPMI function 0x507 ). That works well with the _TEXT section ( code ), but causes a page fault if I also want to protect CONST & CONST2 segments: Here's the relevant part of the map file:

BEGTEXT                CODE           AUTO           00401000        00000010
_TEXT                  CODE           AUTO           00401010        0003a5ef
CONST                  CONST          .rdata         0043c000        00003e38
CONST2                 CONST          .rdata         0043fe38        00008500
_NULL                  BEGDATA        DGROUP         00449000        00000004
_AFTERNULL             BEGDATA        DGROUP         00449004        00000000

The reason for the page fault is in file clib/doslfn/c/inirmlfn.c:

char                    * const __lfn_rm_tb_linear = 0;
unsigned short          const __lfn_rm_tb_segment = 0;
static unsigned short   __lfn_rm_tb_selector = 0;
#define TOTAL_RM_TB_SIZE_PARA   __ROUND_UP_SIZE_TO_PARA( RM_TB_PARM1_SIZE + RM_TB_PARM2_SIZE )
static void init( void )
/**********************/
{
    __lfn_rm_tb_selector = __alloc_dos_tb( TOTAL_RM_TB_SIZE_PARA,
                                      (unsigned short *)&__lfn_rm_tb_segment );
    if( __lfn_rm_tb_selector == 0 ) {
        __fatal_runtime_error( "Unable to allocate LFN real mode transfer buffer", -1 );
        // never return
    }
    *(long *)&__lfn_rm_tb_linear = TinyDPMIBase( __lfn_rm_tb_selector );
}

There are 2 variables, __lfn_rm_tb_linear and __lfn_rm_tb_segm, declared as "const", but nevertheless modified here. Is there a reason for this strange definition? Shouldn't the compiler complain?

Nevertheless, after replacing this file with a modified one without that "const" attribute for the 2 variables, everything works.

[jmalak]

You are right it is problem for DPMI code if you use such protection.
I cannot remember for any reason why these symbols should be in constant segment.
I will change it.

Anyway such definition not define const variable only put variable into const segment that for compiler variable can be changed.
It works if no segment protection, but generaly it is not "valid" code. May be some other variables could have same issue as __saved_DS.
Compiler doesn't complain about such code because it is valid C code with writable variables but located in read only segment.