flat assembler
Message board for the users of flat assembler.
Index
> Windows > Converting MS-DOS applications to Win32 |
Author |
|
UCM 02 Jun 2006, 22:51
Well, it depends on whether you want to use no macros (more difficult, harder to understand), basic macros (usually better, win32a.inc) or "includes-everything" macros (for quick projects, win32ax.inc).
I am going to use basic macros for this example. Here we go: (sorry if i sound kind of like you are an idiot, but just in case you don't know) Code: format PE console 4.0 ;this tells you that it is PE (windows) and uses the console ;if you use console in this, then you will not have to use AllocConsole include 'win32a.inc' ;macro package; you need to have the FASM include directory in your %INCLUDE% environment variable entry start ;this tells you where the program starts, which is "start:" below. section '.data' data readable writeable ;this is where you put your data. "readable writeable" sets access restrictions on this section. ;for this program, there is no data, so nothing goes here. You could also omit the previous line, since an empty section ;doesn't do anything and could cause the program to be un-runnable under some Windows installations. section '.code' code readable executable ;think about it. start: ;entry point mainloop: jmp mainloop ;to exit the program: invoke ExitProcess,0 ;this is a Windows API function call. You always use 'invoke' for API calls. 0 is the error level, normally use 0 for no error and >0 for error. section '.idata' data readable ;this is a section for imports ;now, you have to define where the API calls are coming from. This is where this section comes in, you tell Windows what DLL you are importing from, ;and then you tell it which functions to import and where to put their addresses. FASM's macros then put labels where Windows puts the functions' addresses, so you can call them with invoke. data import ;tells FASM this is an import block library kernel32,'kernel32.dll' ;this tells you which DLLs to load. ExitProcess is in kernel32.dll, so you use that. For conversion from DOS->Windows, you'll probably only ever need kernel32, since it contains all command line access functions. import kernel32,\ ;which DLL to import from ExitProcess,'ExitProcess' ;this function should be imported ;You could replace the 'import kernel32,.... ' part with "include 'apia\kernel32.inc' to save time, it automatically puts in all kernel32 functions for you. ;If you declare a function that you do not use, it is not included in the resulting file. end data ;this is the end of the import section. Phew! P.S. If you don't have it already, download the "Win32 API reference" from the FASM documentation page, and use "WIN32.HLP" as a reference for API functions. _________________ This calls for... Ultra CRUNCHY Man! Ta da!! *crunch* |
|||
02 Jun 2006, 22:51 |
|
saigon 03 Jun 2006, 09:34
Thank you! Just for notice: I have all the references needed to create applications faster. (I have the Win32 API Reference, MSDN Library 6.0a, and I have a book called "Learning Assembly - Second Edition")
I have just one question: If I use the example above that you posted, am I able to use DOS interrupts (int commands) without much hassle? Thanks! EDIT: I might sound/look like a newbie, but I just hate includes . I edited your source and now I have this: Code: format PE console 4.0 entry main section '.code' code readable executable main: mainloop: jmp mainloop ret push 0 call [ExitProcess] section '.idata' data readable dd 0,0,0,RVA kernel32,RVA kernel32_import dd 0,0,0,0,0 kernel32_import: ExitProcess dd RVA _ExitProcess dd 0 kernel32 db 'KERNEL32.DLL',0 _ExitProcess dw 0 db 'ExitProcess',0 There's no need for invoke or the macroinstrucions The only problem is maybe the DOS interrupts, I don't think they work in PE Console format. |
|||
03 Jun 2006, 09:34 |
|
UCM 03 Jun 2006, 12:42
DOS interrupts, unfortunately, are not going to work (you will get an exception and it will crash.) You will have to scour the Win32 API to find the functions with similar functionality.
|
|||
03 Jun 2006, 12:42 |
|
saigon 03 Jun 2006, 12:47
Yeah, I knew this would happen. I got a part done to write to the console using the WriteConsole API, now I just have to finish the part dealing with input and I'm ready. Thanks!
|
|||
03 Jun 2006, 12:47 |
|
comrade 03 Jun 2006, 20:50
'just'
|
|||
03 Jun 2006, 20:50 |
|
saigon 03 Jun 2006, 21:10
huh?
What do you mean comrade? |
|||
03 Jun 2006, 21:10 |
|
comrade 03 Jun 2006, 21:27
you make it sound easy
Quote: now I just have to finish the part dealing with input and I'm ready |
|||
03 Jun 2006, 21:27 |
|
rugxulo 03 Jun 2006, 21:45
Okay, first of all, I know nothing about Windows!
Anyways, UCM, your example assembles okay in FASM 1.66, but (like you alluded) won't run for me (Win XP Home SP2) unless I comment out the empty data section. Also, I tried including a DOS stub (a simple .COM util of mine), but it doesn't seem to run consistently.
Anyone tested dual .EXEs before? Do they work? Can you post examples? What OSes do what? (I doubt it's a FASM bug, but who knows?). |
|||
03 Jun 2006, 21:45 |
|
UCM 03 Jun 2006, 23:34
Try using MZ's instead (read the manual...)
COMs will not have the memory in the correct place (i think) Though, command line parameters will probably be harder. (I don't have much experience with DOS though.) _________________ This calls for... Ultra CRUNCHY Man! Ta da!! *crunch* |
|||
03 Jun 2006, 23:34 |
|
saigon 04 Jun 2006, 07:35
comrade wrote: you make it sound easy I thought it isn't hard I mean that I am very advanced with Win32 API stuff, but the only problem with it is the communication between FASM and the API. That's why I can't say I'm an expert. However, the input handling using Win32 API isn't that hard, so, I put the 'just' there. Anyway, as I said above, I might sound/look like a newbie. But please don't understand me wrong. I am stepping into the advanced level in FASM and propably into expert in Win32 API. And, just for notice, I am 14 and my primary language isn't english, so I may make typos or say something people won't understand the way I wanted. Anyway, enough off-topic for this thread |
|||
04 Jun 2006, 07:35 |
|
rugxulo 06 Jun 2006, 03:11
UCM wrote: Try using MZ's instead (read the manual...) Well, last I checked, the manual claimed it converted any .COMs into .EXEs if the MZ header wasn't found. Maybe I should just use LZEXE's COMTOEXE and see if that helps... |
|||
06 Jun 2006, 03:11 |
|
UCM 06 Jun 2006, 11:46
It says that it "converted binary files to MZ's".
I'm not sure if it knows what starting address your COMs are at (100h). |
|||
06 Jun 2006, 11:46 |
|
saigon 06 Jun 2006, 11:54
I have read the manual through and through, and I got a simple hello world done from scratch using the "format MZ" header. I have not much experience in DOS either, but I am just learning it. About COMs, I don't know much of this format, but from what I see, its size is smaller than the one of MZs. I'll stick with COM (no problems so far).
|
|||
06 Jun 2006, 11:54 |
|
rugxulo 06 Jun 2006, 20:33
Well, COMTOEXE seems to work fine where the FASM-converted .COM stub didn't. Anyways, snipping out the "org 100h" and reassembling the .COM didn't help.
Might be a bug in FASM (though I doubt it, I'm probably doing it wrong). The real question is why does a direct .COM stub work in DR-DOS and not MS-DOS?? Last edited by rugxulo on 12 Oct 2016, 00:31; edited 2 times in total |
|||
06 Jun 2006, 20:33 |
|
Tomasz Grysztar 11 Jun 2006, 19:50
It appears it was indeed a bug in fasm, overlooked for a long time (just a one wrong instruction). Please try the updated version.
|
|||
11 Jun 2006, 19:50 |
|
rugxulo 13 Jun 2006, 00:29
Okay, I reassembled with the new (June 11) revision of FASM. Then, I retested all the DOSes mentioned above, and now they all work.
Kudos! |
|||
13 Jun 2006, 00:29 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.