Why isn't this code working?? (MASM) 1

[kindnumber9]

I'm using MASM 6.15 for assembling using the switches /c (dont link) and /coff (coff object file format). With link i use the switches /entry:start /subsystem:console. There are no assemble or link errors. When I run the final exe a console opens and windows gives the error "new.exe has encountered an error...etc" and then the console closes. I'm running windows xp pro if it matters... I'm just getting into assembly so I'd really like to find out what's wrong with this code so I can continue learning it.

TIA if you can help me!

.386
.MODEL FLAT

.STACK 4096

.DATA

.CODE
_start:
MOV ah, 4CH
MOV al, 0
int 21h

PUBLIC _start

END

 

[Salem]

int21 is a 16-bit API.
You're using a 32-bit OS.
You're about 10 years too late with your code.

Whilst you can write win32 in ASM, it is a whole different set of calls to what used to be done with DOS.

--

 

[kindnumber9]

I know its old, but it should still work shouldn't it? It works in NASM.

 

[kindnumber9]

Can't find an edit option...

Can you tell me what's required for low level, platform independant I/O apart from include files? I know it has something to do with hardware interrupts. I don't expect an elaborate explanation, a book or article online will do

 

[Salem]

> I know its old, but it should still work shouldn't it? It works in NASM.
Well I guess NASM is creating a 16-bit program for you rather than a 32-bit program.

> With link i use the switches /entry:start subsystem:console.
I've no idea, but maybe pick a different subsystem if there is such a thing.

> low level, platform independant I/O apart from include files?
There's no such thing as low level AND platform independent. If you get low enough (which is implied by using ASM to begin with), then by definition it is most definitely platform DEPENDENT.

--

 

[kindnumber9]

Thanks Salem. You're right, NASM was producing 16 bit COM files. I decided to can MASM for now and stick with NASM as it seems easier to use.

>There's no such thing as low level AND platform independent. >If you get low enough (which is implied by using ASM to begin >with), then by definition it is most definitely platform >DEPENDENT.

I know it depends on the hardware. What I really meant was OS independent. Operating systems typically have their own routines to interface with installed hardware right? What i'm wondering is HOW they do it.

 

[bluetongol]

i think, all your program does is to terminate
and return to dos..thats what int 21h function
call 4ch does..

try removing "PUBLIC _start"..this might be
the one that is causing the error.

 

[TessaBonting]

Try just saying .MODEL LARGE then windows will accept it
as being a 16 bit common DOS kind of program.
If you run it, windows see's its a REAL mode program and
will use the DOS INT code's.

You will just get the message: program terminated normaly, since you do nothing more than start en en the program.

Succes, Tessa

 

[kindnumber9]

Ok thanks for the replies. One more question though, are there any books about port programming using assembly?

 

[zeitghost]

Which ports do you want to program?

There were lots of books on dos assembler programming, some of which described programming ports.

 

[kindnumber9]

Are there any books on general hardware interfacing using asm? Apparently not all hardware, esp. peripherals, use i/o ports anymore.

 

[zeitghost]

They all use i/o ports, it's just that Windoze(tm) does all the handling for you & denies you direct access unless you write dlls or drivers.

 

[kindnumber9]

Well from what I understand some hardware use specific areas in memory for I/O ("memory mapped I/O"), so you don't have to use the in/out instructions. My problem is understanding when to use ports and when to use memory or interrupts, and what port/memory/interrupt to use, and what function to use.

I found a book on amazon called "PC Handbook" that seems like a good reference, and Ralf Brown's interrupt list has helped quite a bit... Any other resources like these?

 

[bluetongol]

kindnumber9, we have the same problem. There seems to be
limited resources when it comes to tweaking the different
I/O ports.

I had no problems when my OS was still Win98. XP is very
protective of the system.

 

[zeitghost]

I have a number of ancient dos books that list i/o addresses and memory addresses for stuff like the serial ports, parallel ports, interrupt controllers etc.

These were written when the ISA bus was still current.

Some of it still applies, but a lot doesn't anymore.

 

[kindnumber9]

What are these books you mention? I should be able to figure out what applies and what doesn't.