Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#17 Windows support

open
Stas Sergeev
None
5
2012-11-02
2004-03-13
japheth
No

Hi,

currently most (or all) borland 32-bit dpmi clients -
which use 32RTM.EXE dont execute in DOSEMU. One reason
for this seems to be that interrupt 67h is zero in
DOSEMU. 32rtm.exe (at least the version coming with
BC4) checks if cpu is in protected mode (with SMSW
instruction) and if yes, if firmly assumes that int 67h
is set and executes this int, causing DOSEMU to terminate.

I wrote a simple tsr which sets this vector. after
executing this app I'm able to run TASM32.EXE V5 (this
is valid only for the current developer version of
DOSEMU!!!!). Other tools like TLINK32.EXE or BCC32.EXE
still dont work, but they no longer terminate DOSEMU.

Of course it would be much better to set this vector in
DOSEMU itself and so to avoid wasting memory with a
silly TSR - thats the request finally :-)

Japheth

Discussion

1 2 3 4 > >> (Page 1 of 4)
  • Stas Sergeev
    Stas Sergeev
    2004-03-13

    Logged In: YES
    user_id=501371

    int 67h is a EMS interrupt, it is NULL only as long as the
    ems.sys in not loaded.
    I have ems.sys loaded, int 67h is not NULL for me, and
    tasm32 still doesn't work.
    There might be something wrong here. Please clarify.

     
  • japheth
    japheth
    2004-03-13

    Logged In: YES
    user_id=982058

    this is a very interesting problem.
    - as already mentionedi I use tasm32 V5 and 32rtm.exe from BC4
    - it works with freedos and msdos 7.1
    - I restored msdos.c throwing away my modifications - still
    works
    - changed dpmi memory from 0x20000 (128 MB) back to 0x5000
    MB - still works (in case youre wondering: bcc32.exe
    allocates that much of (uncommitted) memory)

    But: if I execute FTE.EXE (a DJGPP application), then TASM32
    crashes
    Some RE shows: at least this version of 32RTM.EXE expects
    HIWORD of edx, ebx, esi and edi to be cleared at program
    entry. Since DOS doesnt change this, it may depend on the
    programs executed earlier.

    I wrote a small tool with debug to clear hiwords. So I would
    suggest to execute it just before running tasm32. It may help

    Japheth

     
  • Stas Sergeev
    Stas Sergeev
    2004-03-13

    Logged In: YES
    user_id=501371

    I also have tasm32 V5.0 and 32rtm V1.5
    Your prog doesn't help in my case.
    Note that tasm32 never crashed dosemu for me, neither
    does any other 32rtm-based app. It just doesn't work,
    just exits immediately.

    (in case youre wondering: bcc32.exe
    allocates that much of (uncommitted) memory)
    In case you are wondering, the amount of an uncommitted
    memory is not limited by $_dpmi setting. Actually even
    the committed memory that was allocated as uncommited is
    not accounted, so you can commit any amount of
    memory and effectively bypass the $_dpmi restriction.
    So $_dpmi only limits the amount of the committed memory
    you can allocate, and nothing more.

     
  • Logged In: NO

    I also have tasm32 V5.0 and 32rtm V1.5
    Note that tasm32 never crashed dosemu for me, neither
    does any other 32rtm-based app. It just doesn't work,
    just exits immediately.

    Ok, I tested with rtm32 V1.0. This version terminates
    dosemu if vector int 67 is NULL


    Your prog doesn't help in my case.

    yes, it only may help for 32rtm.exe v1.0


    I've got 32rtm.exe V1.5 now and tested it. TASM32 works,
    but only with the already mentioned patch of clearing
    HIWORD(eax) in post_extender for functions 0x3F and 0x40,
    something like:

    if (DPMI_CLIENT.is_32)
    DPMI_CLIENT.stack_frame.eax =
    DPMI_CLIENT.stack_frame.eax & 0xFFFF;


    In case you are wondering, the amount of an uncommitted
    memory is not limited by $_dpmi setting.

    Hmm, are you sure? I really doubt it. BCC32 doesnt run with
    20 (or 64) MB dpmi memory setting. And it mostly allocates
    uncommitted memory. BTW, if you want to test it, you can
    use this PE loader I mentioned here and there. Download it
    from http://www.japheth.de/download/dpmildxx.zip.
    extract it to a directory in your path and execute:

    DPMILD32 BCC32 -c xxxx.c

    Japheth

     
  • Logged In: NO

    I also have tasm32 V5.0 and 32rtm V1.5
    Note that tasm32 never crashed dosemu for me, neither
    does any other 32rtm-based app. It just doesn't work,
    just exits immediately.

    Ok, I tested with rtm32 V1.0. This version terminates
    dosemu if vector int 67 is NULL


    Your prog doesn't help in my case.

    yes, it only may help for 32rtm.exe v1.0


    I've got 32rtm.exe V1.5 now and tested it. TASM32 works,
    but only with the already mentioned patch of clearing
    HIWORD(eax) in post_extender for functions 0x3F and 0x40,
    something like:

    if (DPMI_CLIENT.is_32)
    DPMI_CLIENT.stack_frame.eax =
    DPMI_CLIENT.stack_frame.eax & 0xFFFF;


    In case you are wondering, the amount of an uncommitted
    memory is not limited by $_dpmi setting.

    Hmm, are you sure? I really doubt it. BCC32 doesnt run with
    20 (or 64) MB dpmi memory setting. And it mostly allocates
    uncommitted memory. BTW, if you want to test it, you can
    use this PE loader I mentioned here and there. Download it
    from http://www.japheth.de/download/dpmildxx.zip.
    extract it to a directory in your path and execute:

    DPMILD32 BCC32 -c xxxx.c

    Japheth

     
  • Stas Sergeev
    Stas Sergeev
    2004-04-03

    Logged In: YES
    user_id=501371

    Hello.

    There were many problems with my patch that as a side-effect
    made the "alloc linear mem at fixed addr" working, it
    appeared to have much more side effects than I expected.
    Now with the collective efforts everything seems to be
    rectified.

    I implemented the 32bit wrappers around DOS read/write
    and tasm32 now works indeed - thanks for your bug-hunting!
    Perhaps now you can remove the dosemu-specific code from
    your extender?

    yes, it only may help for 32rtm.exe v1.0
    Does the 32rtm 1.0 work with out-of-the-box dosemu now?

    Hmm, are you sure? I really doubt it. BCC32 doesnt run
    with 20 (or 64) MB dpmi memory setting.
    OK, yes, you were right. This was changed as yet another
    side-effect of the aforementioned patch.
    This is now fixed, only the committed mem is accounted, and
    is accounted properly, i.e. when you commit a previously
    uncommitted memory, it is also accounted, so committing
    can fail if the limit is reached.

     
  • Stas Sergeev
    Stas Sergeev
    2005-07-09

    Logged In: YES
    user_id=501371

    Lets convert this thread to the "Windows support" discussion.

     
  • Stas Sergeev
    Stas Sergeev
    2005-07-19

    Logged In: YES
    user_id=501371

    FYI, Bart made the VGA emulator compatible with your
    VESA driver for Win3.1 - this all now in CVS.

     
  • japheth
    japheth
    2005-07-27

    Logged In: YES
    user_id=982058

    Thanks for the info. BTW, it is not "my" driver, it is
    copyright MS.

    Another BTW: It took me quite a while until "make" was
    willing to create the x plugin, I had to add manually
    "plugin/x" in line PLUGINSUBDIRS= in file Makefile.conf. Is
    this normal or what am I doing wrong?

     
  • japheth
    japheth
    2005-12-21

    Logged In: YES
    user_id=982058

    Hello,

    I added some features for my hx dos extender and it is now
    able to run Quake 2 (Win32) in dosemu. But it seems there is
    a bug in FreeDOS, MSDOS has to be used.

    the hx binaries required are:

    http://www.japheth.de/Download/HXRT.zip
    http://www.japheth.de/Download/HXGUI.zip

    SB16 sound works with Q2, but network still is todo!


    Another extension to HX is SDL support. Some SDL apps I
    tested successfully in DOS, but none works in dosemu.
    I suspect the hx thread implementation not being compatible
    with dosemu. Possibly one could extend dosemu's dpmi host a
    bit? The one thing to do is, if a client is on the locked
    stack and sets the trace flags in the IRET stack frame, this
    flag should be copied to the application stack (and cause an
    exception 01 then).

     
1 2 3 4 > >> (Page 1 of 4)