14 replies to this topic

[untitled_1]

This code wont work on my windows 7, plz help

.586

.model small


	

;----------------------------------------------------

;data segement

;----------------------------------------------------

.data 

	message db "Hello world", 0

	


;----------------------------------------------------



;-----------------------------------------------------

;code segment

;-----------------------------------------------------

.code

	

	start:

		mov ah, 09h	;dos function to print string

		mov edx, offset message	;address of string to be printed

		int 21h				;call interrrupt

		

		

		

	end start

Edited by dargueta, 17 June 2011 - 08:18 AM.
Please use [code][/code] tags!

[Gunner]

That is correct, you cannot use interupts in Win7... There is no DOS (DOS is dead) The command prompt you see in Win 7 is NOT DOS so you cannot use interupts. Maybe if you install a DOS emulator

[RhetoricalRuvim]

Windows 7 doesn't like applications to use system level instructions such as INT, IN, OUT, etc.

Would Windows Vista allow that, though?

[dargueta]

No version of Windows does natively since Intel implemented rings, at least that I know of. It's a huge security risk because all of those would bypass the OS and allow programs to do a lot of nasty stuff. You're going to have to use standard C functions and link your program with the necessary libraries. You're going to have to declare printf() as an external function; I'm not sure how to do this in TASM (if it'll even allow it), but in NASM you'd put extern printf at the beginning of your code and do something like:

(This is in NASM syntax, translation should be straightforward)

extern _printf

global _main


section .text

_main:

    sub     esp, 4

    mov     DWORD [esp], str_hello

    call    _printf

    add     esp, 4

    ret


section .data

    str_hello:  db "Hello, World!", 0x00

EDIT: Windows XP allows this by "sandboxing" the program, but it has restrictions: 1) Must fit into one segment, i.e. < 64K; 2) Cannot make system calls; 3) Must be a raw binary file, with no headers; 4) Load address is 0x100. Default operation size is 16 bits.

Edited by dargueta, 17 June 2011 - 08:00 PM.

[RhetoricalRuvim]

You could also use Win32 functions.

Like in NASM:

extern MessageBoxA 

import MessageBoxA user32.dll 


section .text use32 

..start: 


call main 


ret 


main: 

  enter 0, 0 

  

  push dword 0 

  push dword the_title 

  push dword the_msg 

  push dword 0 

  call [MessageBoxA] 

  

  xor eax, eax 

  leave 

ret 


section .data 

the_title  db "Hello", 0 

the_msg db "Hello World!", 0 


section .text 

I'm pretty sure you can use other Win32 functions, too, as long as you import them.

To assemble that example program, you would probably type something like:

\nasm\nasm -fobj hello.asm 

\alink\alink -oPE hello.obj 

[RhetoricalRuvim]

Quote

Would Windows Vista allow that, though?

Quote

No version of Windows does ...

What I meant is that if I make a .com file with NASM flat form binary output format, using DOS interrupts, and including the "ORG 0x100" at the beginning of the code file, it would work on Windows XP. I tried it on Windows 7 and it doesn't work. I just don't know whether that is supposed to work on Windows Vista.

[dargueta]

It'll work on XP and older. Eventually Microsoft realized that it was a security threat and killed the "feature" from Vista on.

[RhetoricalRuvim]

I don't exactly understand, though, if direct input/output is not allowed, then how does disk-burning software (such as Nero or Cyberlink) work?

[dargueta]

Every device (CD player, DVD etc.) requires a sequence of commands to work. In the old days, these were done through software interrupts the BIOS served. Nowadays, those are extremely old, slow, and aren't designed to handle modern hardware. Instead, we have what are called device drivers. These are functions provided by the operating system (or the manufacturer of the hardware) that allows user-level programs to communicate to the hardware.

However, these functions in turn call special IO routines within the operating system that only the OS can use. First the function makes sure that the driver isn't trying to do something nasty*, then performs the requested IO through IN/OUT functions (not so common anymore), serial ports, COM ports, APCI stuff, etc.

* These are what cause blue screens on Windows computers.

[RhetoricalRuvim]

How do programs access device drivers on Windows? Are there specific functions that they call?

[fayyazlodhi]

Not all drivers can be accessed from C# but generally speaking there is a dll that comes with a device which you need to import into .NET framework.

and

using System.Runtime.InteropServices;

you can access the API. I have used a few drivers such as digital persona's finger print reader device from with in c#

You can google the above namespace and would be able to find samples.
Accessing Device Drivers from C# | Dr Dobb's Journal

would be helpful

Edited by fayyazlodhi, 18 June 2011 - 02:56 AM.
adding correct namespace

[Gunner]

Note sure what place .NET has in an Assembly forum...

You can download the WDK from MS - About the Windows Driver Kit (WDK) Not sure if you can get it on CD anymore (I have the DDK on disk from MS) The DDK (What it used to be called) has source and samples for the sample drivers that come with it. Comes with many tools also for driver development. Even if you are not going to create a driver, it is a good thing to have and look through :-)