I'm trying to enter and run examples from and Advanced C programming book published in '94 that uses the above function. Is there a comparable function for devcpp-4.9.9.2 users? Also, if there is one, does it work the same as int86()?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The code you are attempting to run designed for 16bit MS-DOS. I would suggest that it was probably more Advanced MS-DOS than Advanced C - had the author stuck to the title and used the platform independent standard C library, the book may have had some longevity, but he didn't so you may as well throw it away (or recycle it).
You could use the code with a 16bit compiler - there are several old compilers freely available. But if you did that what would you learn other than out-of-date 'advanced' programming!?
The problem is that int86() which invokes a software interrupt has no relevance in Windows. It is a protected mode operating system that does not allow user level access to system interrupts (not software or hardware interrupts). Even when you run 16 bit code on Windows, the interrupt call is 'virtualised' - it generates an illegal instruction exception that Windows traps and emulates the function of the original interrupt handler - which is much slower, while in DOS such methods were generally used to make things faster! The emulation does not always work that well either, because uses of DOS interrupts were downright nasty and Windows won't countenance some kinds of application behaviour.
int86() would have been used to invoke DOS and BIOS software interrupts. DOS used this mechanism so that user code did not need to know the address of the function entry point. Windows uses DLLs to provide processes with OS function entry points. Rather than hoping for an equivalent to int86(), it makes much more sense to determine which DOS or BIOS function was it intended to invoke in a particular instance, and find an appropriate method suitable for Win32 code.
All in all however, I think you might be better off explaining what you hope to learn from this antique book, and we might be able to propose a more modern resource.
And besides there is not much to 'advance' to in C other than C++ ;) [starts war].
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm trying to enter and run examples from and Advanced C programming book published in '94 that uses the above function. Is there a comparable function for devcpp-4.9.9.2 users? Also, if there is one, does it work the same as int86()?
The code you are attempting to run designed for 16bit MS-DOS. I would suggest that it was probably more Advanced MS-DOS than Advanced C - had the author stuck to the title and used the platform independent standard C library, the book may have had some longevity, but he didn't so you may as well throw it away (or recycle it).
You could use the code with a 16bit compiler - there are several old compilers freely available. But if you did that what would you learn other than out-of-date 'advanced' programming!?
The problem is that int86() which invokes a software interrupt has no relevance in Windows. It is a protected mode operating system that does not allow user level access to system interrupts (not software or hardware interrupts). Even when you run 16 bit code on Windows, the interrupt call is 'virtualised' - it generates an illegal instruction exception that Windows traps and emulates the function of the original interrupt handler - which is much slower, while in DOS such methods were generally used to make things faster! The emulation does not always work that well either, because uses of DOS interrupts were downright nasty and Windows won't countenance some kinds of application behaviour.
int86() would have been used to invoke DOS and BIOS software interrupts. DOS used this mechanism so that user code did not need to know the address of the function entry point. Windows uses DLLs to provide processes with OS function entry points. Rather than hoping for an equivalent to int86(), it makes much more sense to determine which DOS or BIOS function was it intended to invoke in a particular instance, and find an appropriate method suitable for Win32 code.
All in all however, I think you might be better off explaining what you hope to learn from this antique book, and we might be able to propose a more modern resource.
And besides there is not much to 'advance' to in C other than C++ ;) [starts war].
Clifford
Thank you very much, Clifford. I'm just a Visual Basic user that was looking for more in a programming sense than Visual Basic seems to offer.
Search on int86