Hi again, y´all, excuse a beginner, but I just found out reading the excellent book
"Assembly Language for Intel-based computers" 4th Ed, by Kip R. Irvine that these are also availible under XP, is this really correct? :greenclp:
Questions:
1. Are these functions availible under Vista and Windows 7 ?
2. Why does this program with DOS-call give me the assembly error: error A2006:undefined symbol :DGROUP
TITLE Hello World Program (Hello2.asm)
.MODEL small
.STACK 100h
.386
.data
message BYTE "Hello, world!",0dh,0ah
.code
main PROC
.STARTUP
mov ah,40h ; write to file/device
mov bx,1 ; output handle
mov cx,SIZEOF message ; number of bytes
mov dx,OFFSET message ; addr of buffer
int 21h
.EXIT
main ENDP
END
Next chapter is disk fundamentals, and the one after is BIOS -level programming :eusa_dance:
Do not waste your time and throw that book away - 16Bit stuff and DOS is something for the museum.
Search for a x86-32Bit assembler tutorial or book.
I agree with qWord. After x86-32bit, there is x86-64 bit assembly. Why to insist on 16-bit coding?
No, the book is excellent and contain both 16-bit and 32-bit. It starts with a thorough review of most instructions, buildning MACRO's Win32 Console programming, Win32 Window-programming, MS-DOS both basic and memory resident, Disk system and BIOS-level programming.
This book is the shit!!!
Quote from: laskar01 on July 10, 2012, 07:06:41 AM
No, the book is excellent and contain both 16-bit and 32-bit.
[...]
This book is the shit!!!
contradictory statements :icon_eek:
Hi laskar01,
in general, qWord and Vortex are right.
But here is the answer for your questions:
Quotethat these are also availible under XP, is this really correct?
Not really. You may use your INT 21h stuff under XP, but your application runs inside a virtual machine and all interrupts are virtualized. That means: the Windows DPMI Host switches your program for a little while back to the Real Mode, let it do it's interrupt work, and switches back into Protected Mode. That is in a rough overview the used technique,
Quote1. Are these functions availible under Vista and Windows 7 ?
No, that's impossible and has to do with the new Long Mode.
Quote2. Why does this program with DOS-call give me the assembly error: error A2006:undefined symbol :DGROUP
Did you use the right 16 bit linker?
Gunther
The problem with using MS-DOS programming techniques is the 16 bit system was redundant back in the early 1990s. It was replaced first by 16 bit Windows, then from Win95 onwards it was replaced by 32 bit Windows and as of 64 bit Windows, it is not even supported by Windows Virtual Machines. MS-DOS is an antique architecture that depends on a modified 16 bit addressing system that uses segment/offset architecture which is completely incompatible with later protected mode addressing.
64k versus 4 gigabyte address range is one of the main reasons why MS-DOS was left behind long ago.
As far as the Irvine book, do yourself a favour and find another use for it, perhaps a doorstop, packaging for parcels if you tear out the pages and crumple them but do not waste you time or ours on out of date junk. Even the 32 bit code in it is non Intel / Microsoft complaint and uses an unreliable architecture to produce poor quality binaries.
If you bother to learn the modern stuff you use the Windows API functions instead of antique DOS interrupts, you select instructions based on privilege and you use the Intel ABI (Application Binary Interface) so that your register usage is properly compatible with the Windows operating system. If you do this you will be able to write genuine high speed software that runs correctly on all 32 and 64 bit versions of Windows up to Win7 64 bit and your applications will be far more powerful than out of date junk or incompatible architecture can deliver.
you can access some things with 16-bit code that is not so easy with 32 or 64-bit code
when running 16-bit code, newer OS's use NTVDM.exe to emulate or perhaps allow some of these accesses
however, if you write 16-bit code, you run the risk of it not being compatible with future OS's
certainly, it is difficult to run 16-bit programs under 64-bit versions of vista or win 7
but - moving to 32-bit code doesn't seem to be the end-all answer, either
particularly with win7 - drivers essentially must be WHQL digitally-signed ::)
NTVDM is intended to support normal, "well behaved" DOS applications. While it does a good job of this, it will not allow you to do the really interesting low-level stuff that you could do under real-mode DOS. IMO knowledge of what it will allow you to do is today of very limited value, and not worth spending much time on.
Hi, again, you people!
Yes, you were right Gunther, I had to use LINK16. :t
Hutch, I think that most all of us would prepay a book written by you on similar stuff. As it is now, the Irvine book is the only book that deals with assemblyprogramming under Microsoft platforms. I would like to read a book of you, to understand the stuff you've done. ;)
Couldn't find the Intel ABI in the 7 volume Software developers manual. Does anybody have a link?
I would like to do a boot selector that gives me the choice to choose between WinXP and something stupied printed on the screen.
Maybe I am closing in reading the next chapters on memorysystems and BIOS-programming.
Kindest regards,
Lasse
Type "intel abi" into Google. Better info comes from Agner Fog's site. Differentiate between 32 bit and 64 bit, if you write 32 bit, use the 32 bit version, for 64 bit code, use the 64 bit version.
RE: MS-DOS int 21h and int 10h functions, these are kids stuff alongside the Windows API functions and they assume real mode addressing, a tiny 64k world where modern computers break the 4 gig barrier in 64 bit.
Never assume that because something was printed in a book that it is useful, there are no useful 32 b8it assembler books for Windows and the stuff that is available is antique crap. Fine if you want to write legacy 16 bit real mode code for some hardware functions, just set up a box with MS-DOS 6.22 and off you go but you waste your life and time for any other reason.
The best stuff is online and it has been that way for the last 15 years, use the money save from not buying junk books to buy a big screen and read it all online or locally copied to your hard disk. :bgrin:
I'm not sure if it will run under Windows 8 (due to be released soon) or not, but you can still get JP Software's DOS shell (http://jpsoft.com/index.php), formerly called 4DOS and now known as Take Command. I couldn't find any specific information about compatibility with different Windows OS flavors, but it looks as if it will run under Windows 7.
I've been using 4DOS for years. (Use it now to create my 32-bit assembly-language programs.) So much nicer than Microsoft's dumbass "command prompt". So perhaps one
can write and run 16-bit DOS/INT-21H driven programs under Vista and beyond. (The question "why would anyone want to do that?" is left for the programmer to answer.)
Wait, I just found it:
Quote
Take Command is compatible with any 32 or 64-bit version of Microsoft Windows XP (SP2 or later), 2003, Vista, 2008, Windows 7, and Windows 8. Take Command is available in 32-bit and 64-bit versions.
Try using the standard Microsoft CMD.EXE, it works in 32 bit and 64 bit Windows versions just fine.
LASKAR 01,
I have a copy of Kip Irvine's book: Assembly Language for Intel-Based Computers, and, what QWORD, VORTEX, GUNTHER, and HUTCH have stated is correct. Large sections of his book are obsolete. Still it makes an excellent reference for a beginning assembly programmer. The descriptions of the most used assembly instructions is valuable as an introduction,...because, you will use that information in every assembly language program you write. Also, the code that accompanies the book is overly simplistic; he never invokes that standard Windows API version that is normally used in Windows 32-bit programs...and, you'd be surprised how many people that are using that book as a guide to assembly programming post questions here. Irvine's code works well only with other routines that Irvine has provided with his library,...and, this is by design.
yah...
Kip Irvine and Randy Hyde are both fine authors
their books are a bit outdated, however
while they still provide some good information, it is hard for a beginner to know which parts of the books are usable in win32 and which parts are not
If you want to use Kip's book, check this post (http://www.movsd.com/board/index.php?topic=17846.0) about using his library in parallel to the Masm32 SDK.
Thank you all.
I am finishing the BIOS chapter now, but neither BIOS is availible running MASM under XP, correct? All I have is a managed "BIOS"?
Lasse
Lasse,
you should read Hutchs posts very careful. He is absolutely right, but don't forget the excellent AMD manuals. On the other hand, there is a lot of good information and documentation inside the MASM32 package. We have that due to the honest and diligent work of Hutch and the other volunteers - special thanks to all.
QuoteIf you want to use Kip's book, check this post about using his library in parallel to the Masm32 SDK.
Good hint, Jochen.
Gunther
Quote from: laskar01 on July 11, 2012, 06:35:22 AM
I am finishing the BIOS chapter now, but neither BIOS is availible running MASM under XP, correct? All I have is a managed "BIOS"?
Under XP you have access to the BIOS functions through NTVDM. As to whether or not any of the function calls end up being handled by real-mode BIOS code I don't know, but at many/most of functions will behave as they would under DOS. A small number of the functions will always fail and return an error (for example the BIOS wait functions, Interrupt 15h, functions 83h and 86h), and any attempt by a DOS app to use the BIOS disk functions to access a hard disk will cause the system to terminate the app. And the BIOS will recognize devices that may not exist in hardware. For example, my Windows XP system has one serial port and one parallel port, as reported in the System Information app, but if use the DOS DEBUG program to dump the first 16 bytes of the BIOS data area I get:
-d 40:0
0040:0000 F8 03 F8 02 E8 03 E8 02-BC 03 78 03 78 02 C0 9F ..........x.x...
Which shows that the BIOS POST found the full complement of 4 serial ports and 3 parallel ports. And IIRC I could access these "virtual" ports from a DOS app running under Windows, although obviously I could not attach anything to an external connector to do a function test.
Hi Michael,
QuoteAnd IIRC I could access these "virtual" ports from a DOS app running under Windows, although obviously I could not attach anything to an external connector to do a function test.
That's interesting. It could be that this is a remainder for old hardware. For example: some old scanners are using the TWAIN interface. Should be tested.
Gunther