Creating different exe formats

[yodacool]

Is it possible to get a linker to create a windows PE exe file when your code is basically 16-bit instructions? If not, what modifications would I need to do to get a PE exe file out of it?

What other exe formats are there that you can create with your 16-bit .asm code?
Or do you need to make a different type of obj file first to do that?

[AeroASM]

DOS code which uses interrupts will not work under Windows, and there is not really any better way of converting it than to rewrite it. In Windows you use APIs not interrupts, and a flat memory model not segments.

In terms of building the exe, you need a 32-bit linker. (ml.exe is fine for 16 and 32 bit code). A 32 bit linker comes with the MASM32 code.

[yodacool]

DOS code which uses interrupts will not work under Windows, and there is not really any better way of converting it than to rewrite it. In Windows you use APIs not interrupts, and a flat memory model not segments.

In terms of building the exe, you need a 32-bit linker. (ml.exe is fine for 16 and 32 bit code). A 32 bit linker comes with the MASM32 code.

Windows has its own interrupts in the table, but INT 21h is still there. I run windows and assemble 16-bit code and run it just fine...
And the windows APIs actually call interrupts, perhaps not INT 21h, but they still call interrupts.
As for flat models, I might be able to change the model type to flat in my code, instead of using segments.

[MichaelW]

The linker doesn't know or care what instructions the program uses.The program structure and I/O code of the typical 16-bit program would require so many changes that I doubt a "conversion" would be practical. Most procedures can be made to work with only a few changes, and in some rare cases this might be a reasonable thing to do. Personally, rather than take the time to modify a 16-bit procedure to make it work in a 32-bit program, I would just use the old procedure for a pattern and write a faster, cleaner 32-bit procedure.

[AeroASM]

DOS code which uses interrupts will not work under Windows, and there is not really any better way of converting it than to rewrite it. In Windows you use APIs not interrupts, and a flat memory model not segments.

In terms of building the exe, you need a 32-bit linker. (ml.exe is fine for 16 and 32 bit code). A 32 bit linker comes with the MASM32 code.

Windows has its own interrupts in the table, but INT 21h is still there. I run windows and assemble 16-bit code and run it just fine...
And the windows APIs actually call interrupts, perhaps not INT 21h, but they still call interrupts.
As for flat models, I might be able to change the model type to flat in my code, instead of using segments.

You are not allowed to use interrupts under Windows. When you attempt to run DOS code under windows, it actually runs it under a DOS emulator. The Windows APIs do not call interrupts to do their work.

[QvasiModo]

The Windows APIs do not call interrupts to do their work.

Not to get picky, but Windows does use interrupts, internally. (They're totally different from the DOS ones, and well-behaved programs should use the Win32 API instead of interrupt calls, so for the purposes of the discussion you are still right). :)

[tenkey]

Is it possible to get a linker to create a windows PE exe file when your code is basically 16-bit instructions? If not, what modifications would I need to do to get a PE exe file out of it?

What other exe formats are there that you can create with your 16-bit .asm code?
Or do you need to make a different type of obj file first to do that?

Not likely, the linker that produces PE files does not like segment values (like @data), nor does it like 16-bit offsets. All relocatable addresses must be 32-bit. There must be no references to segment values.

You can generate Win16 (NE) files. Same OBJ as other 16-bit code (OMF).

[MichaelW]

This is a DOS program that has been crudely modified to assemble and link as a PE (than cannot possibly run). The changes I had to make after the file would assemble successfully, before it would link: add a start label, and list the name of the label after the END directive. But I admit that this does not indicate that the linker would not reject some of the same things that MASM rejected, if MASM had not rejected them.

Code Select Expand


;.model medium
.486
.model flat, stdcall
option casemap :none

.stack
.data
        ScreenAddress   equ      0A000h
        ScreenWidth     equ      320
        ScreenHeight    equ      200
        image1        db       "image.raw", 0
        image2        db       "image2.raw", 0
        handle          dw       0
        OpenError       db       "Error during opening file!$"
        ReadError       db       "Error during reading file!$"
        buffer1         db       64000 dup (?)

mydata SEGMENT
buffer2 db 64000 dup (?)
;buffer2 db 1
mydata ENDS

.code

SetMode13h proto
SetTextMode proto
OpenFile proto fname:near ptr byte
ReadFile proto buf:near ptr byte
DisplayImage proto
WaitForKey proto
SetPalette proto
GetTicks proto var:DWORD
Quit proto errorcode:byte

;.startup
start:

    cmp   ax,0
    jz    done
    or    ax,ax
    jz    done
    test  ax,ax
    jz    done
  done:

        ;mov ax,@data
        ;mov ds,ax

        invoke OpenFile, addr image1
        invoke ReadFile, addr buffer1
        call SetMode13h
        call SetPalette
        call DisplayImage
        call WaitForKey
        call SetTextMode
        invoke Quit, 0
;.exit

SetMode13h  proc uses ax
            mov         ax, 13h
            int         10h
            ret
SetMode13h endp

SetTextMode proc uses ax
            mov         ax, 3
            int         10h
            ret
SetTextMode endp

OpenFile proc uses ax dx cx fname:near ptr byte
        ;mov         dx, fname
        mov         cx, 0
        mov         ah, 3Dh
        int         21h
        mov         handle, ax
        jc          error
        ret
error:
        ; w AX jest kod bledu
        ; display an error message
        ;mov       dx, offset OpenError
        mov         ah, 9
        int         21h
        ; wait for a key
        mov         ah, 0
        int         16h
        ; exit
        invoke Quit, 1
        ret
OpenFile endp

ReadFile proc uses ax bx cx dx buf:near ptr byte
        mov bx, handle
        ;mov dx, offset buffer1
        mov cx, 64000
        mov ah, 3fh
        int 21h
        jc error
        mov bx, handle
        ;close file
        mov ah, 3eh
        int 21h
        ret

error:
        ; display an error message
        ;mov dx,offset ReadError
        mov ah,09h
        int 21h
        ; wait for a key
        mov ah, 0
        int 16h
        invoke Quit, 2
ReadFile endp

DisplayImage proc uses ax bx cx dx di es
        ;mov si, offset buffer1
        mov di, ScreenAddress
        mov es, di
        xor di,di
        mov cx, 64000
loop1:
        movsb
        LOOP loop1
        ret
DisplayImage endp

SetPalette proc uses ax cx dx
        mov cl, 255
loop1:
        mov al, cl
        mov dx, 3C8h
        out dx, al
        sar ax, 2
        mov dx, 3C9h
        out dx, al
        out dx, al
        out dx, al
        LOOP loop1
        ret

SetPalette endp

GetTicks proc uses ax cx dx var:DWORD
    xor ax,ax
    int 1ah
    mov   word ptr var, dx        ; Store the result (lo)
    mov   word ptr var+2, cx      ; (hi)
    ret
GetTicks endp

WaitForKey proc uses ax
        mov ah, 0
        int 16h
        ret
WaitForKey endp

Quit proc uses ax errorcode:byte
        mov ah, 4ch
        mov al, errorcode
        int 21h
        ret
Quit endp

end start


[greyrabbit]

As other people had said, windows APIs do call interrupts, namely, int 2eh.

[hutch--]

Its no secret that old versions of win95 allowed some of the old DOS interrupts to be used but they were excluded in later Windows versions and you cannot normall call an interrupt from 32 bit code. You find int 2Eh in NTDLL.DLL but unless you want to write in ring0, you can forget the Windows specific interrupts and the old DOS ones.

16 bit code does run in most instances under later versions of Windows but it is built as 16 bit code, not as 32 bit code. The Portable Executable specification for Windows is currently a 32 bit only specification so as Tenkey made the point, you cannot use 16 bit addressing, segments or DOS interrupts. You can play with the FS and GS segments at your own risk but they are reserved and used occasionally by the OS so you live dangerously by doing so.

If you have 16 bit functionality that you want to use in 32 bit code, you will have to rewrite it as 32 bit code.

[Vortex]

Can someone give an example code with int 2Eh from NTDLL.DLL ?

[hutch--]

Vortex,

The easiest thing to do is decompile NTDLL.DLL as there are enough samples through it. From memory I was looking for the internal version of WaitForSingleObjectEx() when I saw it but there are enough others. Quick read around the net say that int 2Eh is an entry into something else.

[ToutEnMasm]

Hello,
i read Hutch mail,it seem so easy to decompile ntdll.dl that i am curious to know how, and i am very impatient to have the prog that made that.
It seem to me that lib and link coming with masm32 are not the soluce.
Can you tell me more ...?
                                       ToutEnMasm
 

[hutch--]

I have an ancient copy of Win32DASM that works fine on most stuff. I generally use DumpPE but some files are too complex for it.