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?
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.
Quote from: AeroASM on June 06, 2005, 02:01:35 PM
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.
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.
Quote from: yodacool on June 06, 2005, 02:24:22 PM
Quote from: AeroASM on June 06, 2005, 02:01:35 PM
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.
Quote from: AeroASM on June 06, 2005, 03:57:09 PMThe 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). :)
Quote from: yodacool on June 06, 2005, 01:46:09 PM
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).
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.
;.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
As other people had said, windows APIs do call interrupts, namely, int 2eh.
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.
Can someone give an example code with int 2Eh from NTDLL.DLL ?
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.
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
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.