the boorland family of compilers as far as i know allows the use of int86() and int86x() functions. But the minGW compiler is not recognizing these functions. Is there any replacement in minGW for them or in other case what should i do to call ROM-BIOS interrupts?
You should be able to do that by using inline assembly code. Your compiler docs and Google should help you with that.
If you are using a modern operating system you may be prevented from actually accessing the BIOS or any of the interrupt routines. Any of the Windows versions after WIN95 will not allow direct access to the real mode interrupt routines.
Jim
MinGW is a 32-bit compiler. Using DOS or BIOS interrupts from 32-bit mode is nonsensical and will not do anything except crash your program.
@jimblumberg: A 16-bit DOS program can call DOS and BIOS interrupts, but they are emulated by Windows, you're not getting the real thing.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
It means there is no way to call ROM BIOS interrupts in modern OS?
What exactly are you trying to do? There are possibly other better ways than playing with BIOS.
Jim
That's what it means. Jim is giving you very good advice...Originally Posted by C_programmer.C
But it begs a question... Is this part of a course you're taking?
If so, you might want to acquaint your teacher with operating systems more modern than those used by Fred Flintstone.
Last edited by CommonTater; 04-12-2011 at 07:48 AM.
No, it is not the part of my course. I just wanted to reading the book "turbo c by Robert Lafore". The function int86() is used in its example code.i just tried to implement them in Turbo C compiler. There it worked well. But in minGW it was not working.
Well its mean that neither i can call ROM BIOS interrupts nor I can access the CPU registers directly?
You should probably be better getting a different book (not to mention a different course, if this is the best they can come up with as a reference).
Your book is about as useful as "Shakespeare's guide to modern English Usage". Useful in it's time no doubt, but the world has moved on.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Also I want to ask whether in modern OS I can access video memory RAM directly using far pointers or not as in Turbo C it works like this
Code:int main() { int far *fptr=0x0B8000000; *fptr='A'; return 0; }
Which one you prefer?
I guess C++ Reference by Herbert Schildt?
I would throw that book away or return it to the museum where you found it.
The minGW compiler can not produce a 16 bit real mode program that is required to interface to the BIOS. Even if it could interface to the BIOS it would not be able to actually write to the actual hardware. Windows will not allow a user space program to write directly to the hardware. Even Turbo-C can not write directly to the hardware from Windows it is writing to virtual hardware controlled by the operating system. This emulation layer will simulate the actual hardware so in most cases it will appear to be working like bad old DOS.
You can check this link for several modern books available for download.
Jim
Last edited by jimblumberg; 04-12-2011 at 01:06 PM.
> I guess C++ Reference by Herbert Schildt?
That's heading in the wrong direction!
Also, are you learning C or C++?
We have a long list of books here, see the sticky threads.
Though personally I would avoid books aimed at specific compilers, or promising results in an unrealistic timeframe like 21 days.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
> Also I want to ask whether in modern OS I can access video memory RAM directly using far pointers
The brain damage continues - just throw it away now and save yourself a whole world of pain later on.
Your average program works only in virtual memory. ALL access to the hardware is via the OS and device drivers. Yes, these will ultimately access the hardware at some physical address, but unless you're actually writing device drivers, you just don't see devices in terms of memory addresses.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
You can't use far anymore, (and you don't need it). The video address still works - just delete the "far" keyword.
I fondly remember Robert's book - quite nostalgic.
