🚀 go-pugleaf

In article <1992Aug12.222613.14838@usenet.ins.cwru.edu> bbm@po.CWRU.Edu (Brian B. Mathewson) writes:
>
>I know that Microsoft's MASM 6.0 comes with a file which has all the OS/2 1.x
>calls in it so you can create OS/2 1.x programs.  Is there any way to get
>Borland's Turbo Assembler to do the same thing?
>
>I suppose it would be possible to lay down the calls, but the hard part would
>be getting it to create an .EXE file that OS/2 can run.  Is there a utility
>that let's you create a DOS-type .EXE file (but with OS/2 calls) and change
>it into an OS/2 .EXE program?
>
>What about letting you create 32-bit programs?
>
        1. Must have LINK386 (comes with OS/2 2.0) and OS2386.LIB (in
        Developer's Toolkit).

        2. Be aware that 16 bits system calls use Pascal calling
        convention, while 32 bits calls use C calling convention.
        Probably any argument pushed/popped to/from the stack is 4 bytes
        in size for 32 bits system calls.

        3. Be aware some system calls will modify certain registers,
        ECX and/or EDX most of the time, when they return.

        4. The LINK386 can't recognize one record type in the .OBJ file
        generated by TASM, namely record type 88H. All 88H records have
        to be removed before link. You lose nothing by doing this because
        88H is of COMMENT record.

        5. Check the resulting .EXE with EXEHDR (in Toolkit) and you will
        see that all system calls are 16:16 pointers. Look into EXE386.H
        (in Toolkit), find the offset where FIXUP records start, and
        change SOURCE TYPE byte (the second byte) for each record
        corresponding to one system call as the following:
        13H -> 06H
        33H -> 26H
        Study the EXE386.H along with your .EXE for better understanding.

        6. Get back a little bit. Since all system calls are NEAR, you
        must use near CALL. But if you decalre system calls as EXTRN NEAR,
        the LINK386 will refuse to link because they are now self-relative
        references. To work around, decalre system calls as EXTRN FAR and
        put them in data segment, load EAX with the 32 bits offset part and
        CALL EAX.

        7. However, because OS/2 2.0 still use implicite segmented memory
        management where each segment starts at different 64K boundary,
        beginning from the second 64K (00010000H), any reference to data
        segment in the program will trigger an access violation because
        the offset in a segment always begins from 0. (sorry for this long
        sentence) So, if the CS starts at 00010000H and DS,SS at 00020000H,
        creat a numerical variable that will add 00020000H to an item's
        offset and use this variable in place of the offset. You can
        specify where the CODE and DATA should start in .DEF file.

        8. Both EIP and ESP are specified in .EXE header so you don't have
        to do anything about them, and DON'T do anything about them,
        especially the ESP. Directly load ESP with a constant when assuming
        the offset in the stack starts from 0 will trigger another access
        violation.

        TASM is not made for OS/2 2.0 although it's much more better than
        MASM in DOS environment. I took the pain as I asked for it, what
        I don't understand is why IBM don't release detailed descriptions
        about all these 32 bits .OBJ, .LIB and .EXE formats to make my
        DEVELOPEMENT FOR THE OS/2 2.0 efforts easier.
Ping