Can i write with Nasm a win32 .exe file which calls a BIOS function (INT 10h) to output a character?
Or is it not possible?
If not then why?
Posted on 2010-04-11 07:14:51 by applefarm
Windows code can't call BIOS functions - you'll have to assemble to a 16bit DOS app, or step up into the world of 32bit API calls - WriteFile() or WriteConsole().
Posted on 2010-04-11 07:36:46 by f0dder

Windows code can't call BIOS functions - you'll have to assemble to a 16bit DOS app, or step up into the world of 32bit API calls - WriteFile() or WriteConsole().


1. But why "Windows code can't call BIOS functions"? Is there any security restriction built into windows OS that dis-allows calling BIOS?
2. Is it so then that WinAPI functions like "WriteFile" and others actually itself call BIOS functions? How other way can "WriteFile" be implemented right?
Posted on 2010-04-11 07:42:17 by applefarm
1. Windows runs in 32bit protected mode (or 64bit mode if you're running a 64bit version) - you can't call 16bit code from either of these modes. There's various workarounds that could be done, but those would involve either security risks, or too much work for very little benefit. Also, it would be slow.

2. Nope, NT-based Windows don't call down to the BIOS - they have native hardware drivers for all your devices.
Posted on 2010-04-11 07:57:39 by f0dder

1. Windows runs in 32bit protected mode (or 64bit mode if you're running a 64bit version) - you can't call 16bit code from either of these modes. There's various workarounds that could be done, but those would involve either security risks, or too much work for very little benefit. Also, it would be slow.

2. Nope, NT-based Windows don't call down to the BIOS - they have native hardware drivers for all your devices.


2. Do you mean that "WriteFile" is implemented as a call "specialDriver-->WriteBits", where function "WriteBits" talks with monitor so that it position characters into correct position on my monitor? Without needing help from BIOS function?

1. Can i then create win32 executable that firstly turns on the mode that you named- "protected mode"- and then being in that "protected mode" program could call maybe BIOS function?
Posted on 2010-04-11 08:07:48 by applefarm
How can i modify my posted text? I don't see "modify" button here.

1. I understand now that i can't use "INT 10" at all in my win32 exe:
Int 0x10 requires a 16-bit environment, so you can only use it in Real Mode  

http://wiki.osdev.org/Drawing_In_Protected_Mode

So, i can't use BIOS to output a string to a console if i want to use win32 exe, and, i should use functions that OS offers for that.
You said that WinAPI doesn't do BIOS calls, but what about if i link my source code with "C library" and call "_printf" function from there- how is this "_printf" implemented? Does "_printf" calls BIOS or WinAPI or Drivers?
Posted on 2010-04-11 08:24:15 by applefarm
applefarm,

C runtime works in the same environment as your program do. Thus it uses Win32 API to perform its tasks.

Upper right corner of your message contains icons like this: .
Posted on 2010-04-11 08:37:18 by baldr

applefarm,

C runtime works in the same environment as your program do. Thus it uses Win32 API to perform its tasks.

Upper right corner of your message contains icons like this: .


Thx. But what do you suggest for a begginer assembler learner, which wants to start console programs, reading in and writing out symbols, and debugging step by step the code later, which way is best then from those:

1) BIOS calls for reading in and writing out symbols. This should be 16 bit DOS .com files then as i understand?
2) DOS interrupt 21. This also need old .com format only as i understand.
3) WinAPI functions like "_WriteFile", those are very badly understandable and debugable functions. Bios calls are much more clean, also dos calls are clean and understandable. But this approach allows to do modern win32 exe-files and OllyDbg debuges them well.
4) C library functions like "_printf" which inside of them call WinAPI. Those C-functions seem a little bit cleaner and more understandable i think, so it's a better choise for a beginner than approach "3)".

I just don't want to deal with old technologies like ".com"-files and 16 bit code. And i want the code to be as clean and understandable as possible. And i want learn basic concepts at first which where i need to output to console strings, so the cleaner the write down code would be the better. Maybe approach "4" with C Library is best for me then.
Posted on 2010-04-11 08:50:49 by applefarm
I think you pretty much answered your own question already.
I think it's easiest to start with printf(), and perhaps later move to WriteFile() and whatnot.

.com files are indeed a bad idea. They only run on 32-bit OSes, and more and more people use 64-bit OSes (and Windows 7 could well be the last Windows OS that even has a 32-bit version).
The only way to run them on a 64-bit OS is to use an emulator such as Dosbox.
So I think you should just forget about .com files, 16-bit, DOS and BIOS.
The BIOS will probably also be phased out before long. A new standard was developed, under the name of (U)EFI (Extensible Firmware Interface). Apple already uses this on their machines, and PCs will probably follow soon.
Posted on 2010-04-11 09:05:51 by Scali
Thx.
I plan to stay to "printf" then for the start.

Can you say, where from i can download suitable "C Library"? I download and runned "setup.exe" from there:
http://sourceware.org/cygwin/
What i must choose from that complex installation program to install proper "C Library" to my WinXp machine?
Posted on 2010-04-11 09:07:55 by applefarm
applefarm,

You may dynamically link to MSVCRT.DLL full-blown C runtime library. Most Windows installations contain it (check %SystemRoor%\system32 folder).
Posted on 2010-04-11 10:00:45 by baldr
As baldr suggested, the MSVCRT (Microsoft Visual C Runtime) library is what you want under Windows for Standard C Library support, as it is native.

Win32 Demo 11 of NASMX demonstrates how to use printf/scanf/etc... under MSVCRT.
Posted on 2010-04-11 12:19:14 by SpooK