Why doesn't this code run ??

[aryajur]

Why doesn't this code display the letter 'a' when I run it?? I assembled and linked it using Qeditor of MASM version 8 and then executed the exe file from the command prompt on Windows 2000. Nothing happens and the control just returns to the command prompt.


.386
.model flat, stdcall
option casemap :none ; case sensitive

.code

start:
mov dl, 41h
mov ah, 02h
int 10h

mov al, 0h
mov ah, 4ch
int 21h

end start

 

[aryajur]

oops sorry the statement was supposed to be :
int 21h instead of int 10h but it still doesn't work !

 

[zeitghost]

My antique version of MASM generated a program that worked ok under dos.

It worked in a win98 dos box too.

Something funny about Win2K?

It should run a simple int21h call ok.

rgds
Zeit.

 

[AirCon]

Aryajur,

How do you build the EXE. Are you build using menu "Build All" or "Console Build All" ? You must build using the "Console Build All".

Try again and let us know

-- AirCon --

 

[aryajur]

Ok, I tried it with the Console Buil All option all, still the same result. I tried it in Win XP also and there the system says there is a fatal error. In windows 2000 nothing happens except the control returns to the command prompt. If I remove the second interrupt call (The one to exit the program) still the same thing happens.
Any more suggestions??

 

[AirCon]

Sorry, I didn't test your code.
Ok I had tested it and got error too. I think the reason is because MASM compiler higher than version 6.11 always build a COFF format (Win32 EXE).

That's why we have to include ".model flat stdcall". And this is the reason why it failed.

So you have to compile using MASM 6.11 or earlier to produce a real DOS EXE format (16 bit DOS EXE), and change the model to ".model small"

If you still want to compile using MASM higher than 6.11 you have to use API console programming.

Regards

-- AirCon --

 

[aryajur]

Ok I have got ur point. So I have a question, does this mean that in MASM we cannot write assembly codes that would run on any other Operating System or maybe a code to write another OS? Does MASM has this limitation? Please clarify.

 

[AirCon]

I'm not really sure about it. But looking from the EXE file that produced from MASM compiler higher than 6.11, I think it is to make the EXE more compatible to windows OS. You can't even debug (using DOS debugger) the EXE file that produced from the latest MASM compiler.
It gives an error: Error in EXE file!

If you want to run other than windows OS, I suggest use MASM 6.11 (or earlier) or use other asm compiler (i.e.: TASM)

Hope it helps a bit

-- AirCon --

 

[aryajur]

What I don't understand here is isn't MASM supposed to be just an assembler ? I mean when we programmed an 8086 assembly file all that was needed was to transfer control to our program code. Now here in IA 32 Architecture our code is another process. So what does more compatible to Windows OS means. Isn't an assembly file just supposed to be compatible with the processor. Why is the compatibility with the OS becoming an issue?
Which Assembler offers the complete freedom of assembly language programming??

 

[AirCon]

I'm afraid I can't explain this good because I'm not fully understand about this matter also. But I'm trying (anyone please share your knowledge, and correct me if I'm wrong )

First of all, yes you are right. When we program under 8086/88 we are fully in control because DOS has no control! But then under windows, this OS takes control over what our program can do and what can't (protection scheme). Yes we can bypassed this protection, but there are rules in order to do that and we simply must follow the rules of the OS (any OS)

Under DOS, all the code in the program is exactly what we type. Under windows, there are other things that the compiler added into the EXE file. Have you ever look at the EXE file for windows using Hex Editor? If you have, you'll see at the beginning of the EXE file an ASCII string mentioned something like this:

This program cannot be run in DOS mode!

That is the EXE header (PE) that is added by the compiler in order to run under Windows OS. The format of this file also known as COFF EXE format file. Or we can also say "Native Windows 32 bit EXE file format".

If MASM compiler doesn't add that header format, you will have to write your own format so the program can be run by windows. Remember windows using a FLAT memory addressing. And always start at ORG 00401000 (virtual address) as an entry point. Can you create it yourself ? Allocate the program into virtual memory address ? and there are other things that have to be done first before the program can actually run. And this is not a simple job


In UNIX OS (other than windows OS), of course that file won't run. Why ? Because maybe they also have their own EXE format, their own rules. Sorry, I don't know what it is, cause I never play around with UNIX. But I hope you get the picture why the portability between OS's becomes an issue.

This is one of the reason why people choose C/C++. It is much easier to switch between OSes. Even in C/C++, have you ever heard about portability issue. ASM will simply be harder to port to another OS.


Regards

-- AirCon --

 

[aryajur]

Hello Aircon,
Thanks for the elaborate reply, it was definitely helpful. I just have one query, suppose I write the sam program in MASM version 8 and then replace the header with a header compatible to run in DOS, would it then run in DOS or does the format still have differences?

 

[AirCon]

Hmm... I never tried that. Maybe you can experiment yourself :-D

Things that you need to know is the size of PE header. I think it can be different in size ( I haven't go deep into PE header ). Google for PE header

I'm curious why you want to do that. If you just want to create a DOS format, just use MASM 6.11 or earlier (as I mentioned). If you still want to use higher compiler version, why don't you try with console programming ?

Look here for the example:
thread272-597553

-- AirCon --

 

[lionelhill]

There are various issues going on here.

(1) The assembler merely translates your code into machine-readable stuff. It isn't responsible for what state the machine is in before your code starts. That's the role of the operating system. So if you write 32-bit code and arrange for the processor to call it in 16-bit mode (or vice versa), then that's not the assembler's fault.

(2)There are two different things that you are using about which the assembler knows nothing. (A) the operating system service calls, bios, int 021h etc. In your case, these are provided by dos, and belong in the 16-bit world. In 32-bit windows-world they're different. You must know in advance which you intend to use. If you're writing in 32-bit world and try to use 16-bit facilities, things will fail. (B) addressing. That's what "flat" is doing. The assembler will write whatever you ask it to, so if you ask it to write a 32-bit piece of code but use 16-bit facilities, it will comply, because it doesn't know that there isn't a 32-bit operating system out there that handles all the calls you ask for. It doesn't know what operating system you will use to run your software.

(3) The dos stub. The bit about "This program cannot be run in dos mode!" is because Microsoft chose to use .exe as the file type for windows executables. To avoid disasters, they established a pattern of actually making all windows executables simultaneously dos-executables, but to dos they look like a very short, simple program that prints that string and stops. Windows however can extract the "rest" of the code, and run the windows program. In effect, a windows exe can be (but doesn't have to be) a bifunctional file, with two different programs for two different operating systems.

hope that helps a bit

 

[aryajur]

Ok, this thread has been very helpful and informative for me. Though I have one question as a result of the previous responses. I can understand the stuff about the Assembler by lonehill.
My question is that since MASM produces files that can be run in Windows by giving them the special header that windows recognizes and then knows how to make the process out of it and then starts the task, is it possible that maybe I write a small program in C/C++ that will replace the header of this EXE to give it a suitable header that will be recognized in another operating system, or perhaps strip off the header totally and use it as a .bin file to make an OS. Of course by saying this I know that there wouldn't be DOS specific calls or windows specific calls in the code.
What I really want to know is that is it worth adapting to MASM, because if I do adapt to it and then later want to port my program which does not use an OS specific call to another OS then will I have to learn programming in another assembler? I want to adapt to such an assembler which can provide me this freedom. I hope my aim is clear now.

 

[lionelhill]

If you want to port your program, don't use assembler. That was one of the main reasons for inventing higher level languages. The problem is that you will always be dependant on things like operating system calls (or worse still, you can get hardware-specific and write your own mouse handler instead of using the operating system or bios to get mouse positions....). Therefore if you port your software to a different operating system you will have to rewrite it anyway. If you go hardware-specific then you'll have to rewrite it for a different PC even if the operating system is the same!
Basically the best thing is to write all portable code in a portable language (like C, C++, java, whatever suits your requirements), and only write in assembler the bits that really must be in assembler (those that deal with hardware issues at a very intimate level, or those that really need to be optimised for minimal space or maximum speed). These bits you will have to rewrite every time you change OS. Sorry!