[NTVDM]
** WARNING! WARNING! WORK IN PROGRESS!! **
** MEGA HUGE IRC SPAM IN SIGHT!! **
Commit a starting point implementation for 16-bit callbacks from 32-bit code that work together with the EmulatorSimulate / EmulatorUnsimulate functions.
That needs HUUUGE reviewing (go to the END to skip details and going to the current drawbacks of the implementation) <-- [TheFlash], Vampyre, others...
How it is intended to work:
1- Add callback.c to the CMakeLists.txt file, and remove int32.c from it.
2- In some 32-bit module that will get called by 16-bit code sooner or later (e.g. bios32 or dos32), include callback.h instead of int23.h.
3- Add a CALLBACK16 MyContext; // definition
4- In some initialization code for this module, call: InitializeContext(&MyContext, custom_segment, custom_offset);
This allows you to define a zone of memory custom_segment:custom_offset that will be used as a trampoline zone. FIXME/TODO: we can return from this call the size of this zone (not implemented at the moment), so that we can know the zone that will be reserved for calls (it will be used in the following steps).
5- Now you can register e.g. 32-bit interrupt handlers with calls like:
MyContext.NextOffset += RegisterInt32(MAKELONG(MyContext.NextOffset,
MyContext.Segment),
IntNumber, Int32Handler, NULL);
Now comes the tricky part: since we want to be able to give precise memory addresses to where to put interrupt stubs (whose addresses will be stored in the IVT) (it's because it happens that some programs expect some few code interrupts to be placed at given places in memory; or one can argue that it is "for IBM bios compatibility"....), we pass a far pointer instead of the context structure as the first parameter. Then, currently the function returns the size of the written code (and it returns too via its last optional parameter).
6- You can do almost the same with RegisterInt16, where now instead of giving a 32-bit interrupt handler, you give the code of a 16-bit interrupt. What changes here is that in the 32-bit case, the 16-bit interrupt code was generated (to call back the 32-bit handler) whereas here you control it fully. For 16-bit interrupt code you need to use IRETs operands.
7- There is a RegisterCallback16 function, which registers at a given place in memory a chunk of 16-bit code. This code is expected to return with RETs. Its accompanying function RunCallback16 is untested at the moment.
8- Now the magic: Calling this code: an example is given in the following (from DosFastConOut fucntion of Dos32):
<code_snip>
/* Save AX and BX */
USHORT AX = getAX();
USHORT BX = getBX();
setBL(DOS_CHAR_ATTRIBUTE);
setBH(Bda->VideoPage);
setAH(0x0E);
Int32Call(&DosContext, 0x10);
/* Restore AX and BX */
setAX(AX);
setBX(BX);
</code_snip>
Here (after saving some registers and setting some parameters for the INT 10h being called), we call interrupt 10h with Int32Call(&DosContext, 0x10); // where DosContext is a CALLBACK16 context.
The call is done "synchronously", i.e. we restart here CPU simulation. The simulation then stops because the generated trampoline code has a suitable BOP_UNSIMULATE instruction.
CURRENT DRAWBACKS:
==================
1- The module which is going to use those callbacks need to know where in memory the code will be placed. Nothing is done "automatically". Otherwise we would have to:
* maintain a (gobal, and finite) table of callbacks (in some way or another), and/or
* be able to place the code in some "shadowed" memory zone of the emulator that gets hidden for all the programs emulated BUT the emulator.
2- Linked to the previous second point comes the problem of trampoline code. It is needed because we need to put a BOP_UNSIMULATE operand after the code to stop the 16-bit code simulation and go back to 32-bit. We need also to call e.g. INT 0x10 from 16-bit to be able to run the interrupt that could be hooked by some program. Some may argue that one can first call EmulatorInterrupt(0x10); but then we would have to find a means of stopping the simulation as soon as the interrupt exits...
3- For calling "regular" 16-bit code (with RunCallback16) we need a suitable callback: "call far_pointer; BOP_UNSIMULATE" .
4- Currently we build the trampolines on-the-fly when calling either RunCallback16 or Int32Call, at the memory location given when initializing CALLBACK16 context. If a given 32-bit module calls some 16-bit code that calls in turn a 32-bit function from the SAME module which calls also a 16-bit callback, then the trampoline will be overwritten. In RunCallback16 (and Int32Call) we save it, push a new one and then call the 16-bit code, and then restore the old one after the call. It seems to work fine currently, but I've found a problem, I think, which is the following:
* Suppose that a 16-bit program calls some VDD function,
* this VDD function creates a thread,
* the two running VDD functions then call back the 16-bit program, or trigger an interrupt from whatever nature which both call 32-bit functions from a given 32-bit module (bios, dos). In this situation many problems arise:
a. Our current implementation of the emulator doesn't support that since you are going to play concurrently with the unique CONTEXT of the emulated CPU... (i.e. flags / registers corruption in sight)
b. If the 32-bit functions (called concurrently, and which are from the same 32-bit module) call some 16-bit code / interrupt, then they are going to use the same memory zone for the trampoline stub and there are very high risks of corruption. A solution for that would be to generate the trampolines once and for all for each registered 16-bit interrupt stub / 16-bit generic callback, retrieve their addresses and store them in some place (that also get shared amongst all of the 32-bit modules of the NTVDM emulator), so that each (possible concurrent) call go to the trampoline and just make the CPU point at it...
Voilà !
svn path=/branches/ntvdm/; revision=62283
2014-02-21 20:31:56 +00:00
|
|
|
/*
|
|
|
|
|
* COPYRIGHT: GPL - See COPYING in the top level directory
|
|
|
|
|
* PROJECT: ReactOS Virtual DOS Machine
|
2015-09-18 17:01:49 +00:00
|
|
|
* FILE: subsystems/mvdm/ntvdm/cpu/callback.h
|
[NTVDM]
** WARNING! WARNING! WORK IN PROGRESS!! **
** MEGA HUGE IRC SPAM IN SIGHT!! **
Commit a starting point implementation for 16-bit callbacks from 32-bit code that work together with the EmulatorSimulate / EmulatorUnsimulate functions.
That needs HUUUGE reviewing (go to the END to skip details and going to the current drawbacks of the implementation) <-- [TheFlash], Vampyre, others...
How it is intended to work:
1- Add callback.c to the CMakeLists.txt file, and remove int32.c from it.
2- In some 32-bit module that will get called by 16-bit code sooner or later (e.g. bios32 or dos32), include callback.h instead of int23.h.
3- Add a CALLBACK16 MyContext; // definition
4- In some initialization code for this module, call: InitializeContext(&MyContext, custom_segment, custom_offset);
This allows you to define a zone of memory custom_segment:custom_offset that will be used as a trampoline zone. FIXME/TODO: we can return from this call the size of this zone (not implemented at the moment), so that we can know the zone that will be reserved for calls (it will be used in the following steps).
5- Now you can register e.g. 32-bit interrupt handlers with calls like:
MyContext.NextOffset += RegisterInt32(MAKELONG(MyContext.NextOffset,
MyContext.Segment),
IntNumber, Int32Handler, NULL);
Now comes the tricky part: since we want to be able to give precise memory addresses to where to put interrupt stubs (whose addresses will be stored in the IVT) (it's because it happens that some programs expect some few code interrupts to be placed at given places in memory; or one can argue that it is "for IBM bios compatibility"....), we pass a far pointer instead of the context structure as the first parameter. Then, currently the function returns the size of the written code (and it returns too via its last optional parameter).
6- You can do almost the same with RegisterInt16, where now instead of giving a 32-bit interrupt handler, you give the code of a 16-bit interrupt. What changes here is that in the 32-bit case, the 16-bit interrupt code was generated (to call back the 32-bit handler) whereas here you control it fully. For 16-bit interrupt code you need to use IRETs operands.
7- There is a RegisterCallback16 function, which registers at a given place in memory a chunk of 16-bit code. This code is expected to return with RETs. Its accompanying function RunCallback16 is untested at the moment.
8- Now the magic: Calling this code: an example is given in the following (from DosFastConOut fucntion of Dos32):
<code_snip>
/* Save AX and BX */
USHORT AX = getAX();
USHORT BX = getBX();
setBL(DOS_CHAR_ATTRIBUTE);
setBH(Bda->VideoPage);
setAH(0x0E);
Int32Call(&DosContext, 0x10);
/* Restore AX and BX */
setAX(AX);
setBX(BX);
</code_snip>
Here (after saving some registers and setting some parameters for the INT 10h being called), we call interrupt 10h with Int32Call(&DosContext, 0x10); // where DosContext is a CALLBACK16 context.
The call is done "synchronously", i.e. we restart here CPU simulation. The simulation then stops because the generated trampoline code has a suitable BOP_UNSIMULATE instruction.
CURRENT DRAWBACKS:
==================
1- The module which is going to use those callbacks need to know where in memory the code will be placed. Nothing is done "automatically". Otherwise we would have to:
* maintain a (gobal, and finite) table of callbacks (in some way or another), and/or
* be able to place the code in some "shadowed" memory zone of the emulator that gets hidden for all the programs emulated BUT the emulator.
2- Linked to the previous second point comes the problem of trampoline code. It is needed because we need to put a BOP_UNSIMULATE operand after the code to stop the 16-bit code simulation and go back to 32-bit. We need also to call e.g. INT 0x10 from 16-bit to be able to run the interrupt that could be hooked by some program. Some may argue that one can first call EmulatorInterrupt(0x10); but then we would have to find a means of stopping the simulation as soon as the interrupt exits...
3- For calling "regular" 16-bit code (with RunCallback16) we need a suitable callback: "call far_pointer; BOP_UNSIMULATE" .
4- Currently we build the trampolines on-the-fly when calling either RunCallback16 or Int32Call, at the memory location given when initializing CALLBACK16 context. If a given 32-bit module calls some 16-bit code that calls in turn a 32-bit function from the SAME module which calls also a 16-bit callback, then the trampoline will be overwritten. In RunCallback16 (and Int32Call) we save it, push a new one and then call the 16-bit code, and then restore the old one after the call. It seems to work fine currently, but I've found a problem, I think, which is the following:
* Suppose that a 16-bit program calls some VDD function,
* this VDD function creates a thread,
* the two running VDD functions then call back the 16-bit program, or trigger an interrupt from whatever nature which both call 32-bit functions from a given 32-bit module (bios, dos). In this situation many problems arise:
a. Our current implementation of the emulator doesn't support that since you are going to play concurrently with the unique CONTEXT of the emulated CPU... (i.e. flags / registers corruption in sight)
b. If the 32-bit functions (called concurrently, and which are from the same 32-bit module) call some 16-bit code / interrupt, then they are going to use the same memory zone for the trampoline stub and there are very high risks of corruption. A solution for that would be to generate the trampolines once and for all for each registered 16-bit interrupt stub / 16-bit generic callback, retrieve their addresses and store them in some place (that also get shared amongst all of the 32-bit modules of the NTVDM emulator), so that each (possible concurrent) call go to the trampoline and just make the CPU point at it...
Voilà !
svn path=/branches/ntvdm/; revision=62283
2014-02-21 20:31:56 +00:00
|
|
|
* PURPOSE: 32-bit Interrupt Handlers
|
|
|
|
|
* PROGRAMMERS: Aleksandar Andrejevic <theflash AT sdf DOT lonestar DOT org>
|
|
|
|
|
* Hermes Belusca-Maito (hermes.belusca@sfr.fr)
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _CALLBACK_H_
|
|
|
|
|
#define _CALLBACK_H_
|
|
|
|
|
|
|
|
|
|
/* DEFINES ********************************************************************/
|
|
|
|
|
|
2014-09-30 23:47:23 +00:00
|
|
|
#define BOP(num) LOBYTE(EMULATOR_BOP), HIBYTE(EMULATOR_BOP), (num)
|
|
|
|
|
#define UnSimulate16(trap) \
|
|
|
|
|
do { \
|
|
|
|
|
*(PUSHORT)(trap) = EMULATOR_BOP; \
|
|
|
|
|
(trap) += sizeof(USHORT); \
|
|
|
|
|
*(trap) = BOP_UNSIMULATE; \
|
|
|
|
|
} while(0)
|
|
|
|
|
// #define UnSimulate16 MAKELONG(EMULATOR_BOP, BOP_UNSIMULATE) // BOP(BOP_UNSIMULATE)
|
[NTVDM]
** WARNING! WARNING! WORK IN PROGRESS!! **
** MEGA HUGE IRC SPAM IN SIGHT!! **
Commit a starting point implementation for 16-bit callbacks from 32-bit code that work together with the EmulatorSimulate / EmulatorUnsimulate functions.
That needs HUUUGE reviewing (go to the END to skip details and going to the current drawbacks of the implementation) <-- [TheFlash], Vampyre, others...
How it is intended to work:
1- Add callback.c to the CMakeLists.txt file, and remove int32.c from it.
2- In some 32-bit module that will get called by 16-bit code sooner or later (e.g. bios32 or dos32), include callback.h instead of int23.h.
3- Add a CALLBACK16 MyContext; // definition
4- In some initialization code for this module, call: InitializeContext(&MyContext, custom_segment, custom_offset);
This allows you to define a zone of memory custom_segment:custom_offset that will be used as a trampoline zone. FIXME/TODO: we can return from this call the size of this zone (not implemented at the moment), so that we can know the zone that will be reserved for calls (it will be used in the following steps).
5- Now you can register e.g. 32-bit interrupt handlers with calls like:
MyContext.NextOffset += RegisterInt32(MAKELONG(MyContext.NextOffset,
MyContext.Segment),
IntNumber, Int32Handler, NULL);
Now comes the tricky part: since we want to be able to give precise memory addresses to where to put interrupt stubs (whose addresses will be stored in the IVT) (it's because it happens that some programs expect some few code interrupts to be placed at given places in memory; or one can argue that it is "for IBM bios compatibility"....), we pass a far pointer instead of the context structure as the first parameter. Then, currently the function returns the size of the written code (and it returns too via its last optional parameter).
6- You can do almost the same with RegisterInt16, where now instead of giving a 32-bit interrupt handler, you give the code of a 16-bit interrupt. What changes here is that in the 32-bit case, the 16-bit interrupt code was generated (to call back the 32-bit handler) whereas here you control it fully. For 16-bit interrupt code you need to use IRETs operands.
7- There is a RegisterCallback16 function, which registers at a given place in memory a chunk of 16-bit code. This code is expected to return with RETs. Its accompanying function RunCallback16 is untested at the moment.
8- Now the magic: Calling this code: an example is given in the following (from DosFastConOut fucntion of Dos32):
<code_snip>
/* Save AX and BX */
USHORT AX = getAX();
USHORT BX = getBX();
setBL(DOS_CHAR_ATTRIBUTE);
setBH(Bda->VideoPage);
setAH(0x0E);
Int32Call(&DosContext, 0x10);
/* Restore AX and BX */
setAX(AX);
setBX(BX);
</code_snip>
Here (after saving some registers and setting some parameters for the INT 10h being called), we call interrupt 10h with Int32Call(&DosContext, 0x10); // where DosContext is a CALLBACK16 context.
The call is done "synchronously", i.e. we restart here CPU simulation. The simulation then stops because the generated trampoline code has a suitable BOP_UNSIMULATE instruction.
CURRENT DRAWBACKS:
==================
1- The module which is going to use those callbacks need to know where in memory the code will be placed. Nothing is done "automatically". Otherwise we would have to:
* maintain a (gobal, and finite) table of callbacks (in some way or another), and/or
* be able to place the code in some "shadowed" memory zone of the emulator that gets hidden for all the programs emulated BUT the emulator.
2- Linked to the previous second point comes the problem of trampoline code. It is needed because we need to put a BOP_UNSIMULATE operand after the code to stop the 16-bit code simulation and go back to 32-bit. We need also to call e.g. INT 0x10 from 16-bit to be able to run the interrupt that could be hooked by some program. Some may argue that one can first call EmulatorInterrupt(0x10); but then we would have to find a means of stopping the simulation as soon as the interrupt exits...
3- For calling "regular" 16-bit code (with RunCallback16) we need a suitable callback: "call far_pointer; BOP_UNSIMULATE" .
4- Currently we build the trampolines on-the-fly when calling either RunCallback16 or Int32Call, at the memory location given when initializing CALLBACK16 context. If a given 32-bit module calls some 16-bit code that calls in turn a 32-bit function from the SAME module which calls also a 16-bit callback, then the trampoline will be overwritten. In RunCallback16 (and Int32Call) we save it, push a new one and then call the 16-bit code, and then restore the old one after the call. It seems to work fine currently, but I've found a problem, I think, which is the following:
* Suppose that a 16-bit program calls some VDD function,
* this VDD function creates a thread,
* the two running VDD functions then call back the 16-bit program, or trigger an interrupt from whatever nature which both call 32-bit functions from a given 32-bit module (bios, dos). In this situation many problems arise:
a. Our current implementation of the emulator doesn't support that since you are going to play concurrently with the unique CONTEXT of the emulated CPU... (i.e. flags / registers corruption in sight)
b. If the 32-bit functions (called concurrently, and which are from the same 32-bit module) call some 16-bit code / interrupt, then they are going to use the same memory zone for the trampoline stub and there are very high risks of corruption. A solution for that would be to generate the trampolines once and for all for each registered 16-bit interrupt stub / 16-bit generic callback, retrieve their addresses and store them in some place (that also get shared amongst all of the 32-bit modules of the NTVDM emulator), so that each (possible concurrent) call go to the trampoline and just make the CPU point at it...
Voilà !
svn path=/branches/ntvdm/; revision=62283
2014-02-21 20:31:56 +00:00
|
|
|
|
2015-07-07 00:11:18 +00:00
|
|
|
#define TRAMPOLINE_SIZE sizeof(ULONGLONG)
|
|
|
|
|
|
[NTVDM]
** WARNING! WARNING! WORK IN PROGRESS!! **
** MEGA HUGE IRC SPAM IN SIGHT!! **
Commit a starting point implementation for 16-bit callbacks from 32-bit code that work together with the EmulatorSimulate / EmulatorUnsimulate functions.
That needs HUUUGE reviewing (go to the END to skip details and going to the current drawbacks of the implementation) <-- [TheFlash], Vampyre, others...
How it is intended to work:
1- Add callback.c to the CMakeLists.txt file, and remove int32.c from it.
2- In some 32-bit module that will get called by 16-bit code sooner or later (e.g. bios32 or dos32), include callback.h instead of int23.h.
3- Add a CALLBACK16 MyContext; // definition
4- In some initialization code for this module, call: InitializeContext(&MyContext, custom_segment, custom_offset);
This allows you to define a zone of memory custom_segment:custom_offset that will be used as a trampoline zone. FIXME/TODO: we can return from this call the size of this zone (not implemented at the moment), so that we can know the zone that will be reserved for calls (it will be used in the following steps).
5- Now you can register e.g. 32-bit interrupt handlers with calls like:
MyContext.NextOffset += RegisterInt32(MAKELONG(MyContext.NextOffset,
MyContext.Segment),
IntNumber, Int32Handler, NULL);
Now comes the tricky part: since we want to be able to give precise memory addresses to where to put interrupt stubs (whose addresses will be stored in the IVT) (it's because it happens that some programs expect some few code interrupts to be placed at given places in memory; or one can argue that it is "for IBM bios compatibility"....), we pass a far pointer instead of the context structure as the first parameter. Then, currently the function returns the size of the written code (and it returns too via its last optional parameter).
6- You can do almost the same with RegisterInt16, where now instead of giving a 32-bit interrupt handler, you give the code of a 16-bit interrupt. What changes here is that in the 32-bit case, the 16-bit interrupt code was generated (to call back the 32-bit handler) whereas here you control it fully. For 16-bit interrupt code you need to use IRETs operands.
7- There is a RegisterCallback16 function, which registers at a given place in memory a chunk of 16-bit code. This code is expected to return with RETs. Its accompanying function RunCallback16 is untested at the moment.
8- Now the magic: Calling this code: an example is given in the following (from DosFastConOut fucntion of Dos32):
<code_snip>
/* Save AX and BX */
USHORT AX = getAX();
USHORT BX = getBX();
setBL(DOS_CHAR_ATTRIBUTE);
setBH(Bda->VideoPage);
setAH(0x0E);
Int32Call(&DosContext, 0x10);
/* Restore AX and BX */
setAX(AX);
setBX(BX);
</code_snip>
Here (after saving some registers and setting some parameters for the INT 10h being called), we call interrupt 10h with Int32Call(&DosContext, 0x10); // where DosContext is a CALLBACK16 context.
The call is done "synchronously", i.e. we restart here CPU simulation. The simulation then stops because the generated trampoline code has a suitable BOP_UNSIMULATE instruction.
CURRENT DRAWBACKS:
==================
1- The module which is going to use those callbacks need to know where in memory the code will be placed. Nothing is done "automatically". Otherwise we would have to:
* maintain a (gobal, and finite) table of callbacks (in some way or another), and/or
* be able to place the code in some "shadowed" memory zone of the emulator that gets hidden for all the programs emulated BUT the emulator.
2- Linked to the previous second point comes the problem of trampoline code. It is needed because we need to put a BOP_UNSIMULATE operand after the code to stop the 16-bit code simulation and go back to 32-bit. We need also to call e.g. INT 0x10 from 16-bit to be able to run the interrupt that could be hooked by some program. Some may argue that one can first call EmulatorInterrupt(0x10); but then we would have to find a means of stopping the simulation as soon as the interrupt exits...
3- For calling "regular" 16-bit code (with RunCallback16) we need a suitable callback: "call far_pointer; BOP_UNSIMULATE" .
4- Currently we build the trampolines on-the-fly when calling either RunCallback16 or Int32Call, at the memory location given when initializing CALLBACK16 context. If a given 32-bit module calls some 16-bit code that calls in turn a 32-bit function from the SAME module which calls also a 16-bit callback, then the trampoline will be overwritten. In RunCallback16 (and Int32Call) we save it, push a new one and then call the 16-bit code, and then restore the old one after the call. It seems to work fine currently, but I've found a problem, I think, which is the following:
* Suppose that a 16-bit program calls some VDD function,
* this VDD function creates a thread,
* the two running VDD functions then call back the 16-bit program, or trigger an interrupt from whatever nature which both call 32-bit functions from a given 32-bit module (bios, dos). In this situation many problems arise:
a. Our current implementation of the emulator doesn't support that since you are going to play concurrently with the unique CONTEXT of the emulated CPU... (i.e. flags / registers corruption in sight)
b. If the 32-bit functions (called concurrently, and which are from the same 32-bit module) call some 16-bit code / interrupt, then they are going to use the same memory zone for the trampoline stub and there are very high risks of corruption. A solution for that would be to generate the trampolines once and for all for each registered 16-bit interrupt stub / 16-bit generic callback, retrieve their addresses and store them in some place (that also get shared amongst all of the 32-bit modules of the NTVDM emulator), so that each (possible concurrent) call go to the trampoline and just make the CPU point at it...
Voilà !
svn path=/branches/ntvdm/; revision=62283
2014-02-21 20:31:56 +00:00
|
|
|
typedef struct _CALLBACK16
|
|
|
|
|
{
|
|
|
|
|
ULONG TrampolineFarPtr; // Where the trampoline zone is placed
|
2014-05-19 01:12:25 +00:00
|
|
|
ULONG TrampolineSize; // Size of the trampoline zone
|
[NTVDM]
** WARNING! WARNING! WORK IN PROGRESS!! **
** MEGA HUGE IRC SPAM IN SIGHT!! **
Commit a starting point implementation for 16-bit callbacks from 32-bit code that work together with the EmulatorSimulate / EmulatorUnsimulate functions.
That needs HUUUGE reviewing (go to the END to skip details and going to the current drawbacks of the implementation) <-- [TheFlash], Vampyre, others...
How it is intended to work:
1- Add callback.c to the CMakeLists.txt file, and remove int32.c from it.
2- In some 32-bit module that will get called by 16-bit code sooner or later (e.g. bios32 or dos32), include callback.h instead of int23.h.
3- Add a CALLBACK16 MyContext; // definition
4- In some initialization code for this module, call: InitializeContext(&MyContext, custom_segment, custom_offset);
This allows you to define a zone of memory custom_segment:custom_offset that will be used as a trampoline zone. FIXME/TODO: we can return from this call the size of this zone (not implemented at the moment), so that we can know the zone that will be reserved for calls (it will be used in the following steps).
5- Now you can register e.g. 32-bit interrupt handlers with calls like:
MyContext.NextOffset += RegisterInt32(MAKELONG(MyContext.NextOffset,
MyContext.Segment),
IntNumber, Int32Handler, NULL);
Now comes the tricky part: since we want to be able to give precise memory addresses to where to put interrupt stubs (whose addresses will be stored in the IVT) (it's because it happens that some programs expect some few code interrupts to be placed at given places in memory; or one can argue that it is "for IBM bios compatibility"....), we pass a far pointer instead of the context structure as the first parameter. Then, currently the function returns the size of the written code (and it returns too via its last optional parameter).
6- You can do almost the same with RegisterInt16, where now instead of giving a 32-bit interrupt handler, you give the code of a 16-bit interrupt. What changes here is that in the 32-bit case, the 16-bit interrupt code was generated (to call back the 32-bit handler) whereas here you control it fully. For 16-bit interrupt code you need to use IRETs operands.
7- There is a RegisterCallback16 function, which registers at a given place in memory a chunk of 16-bit code. This code is expected to return with RETs. Its accompanying function RunCallback16 is untested at the moment.
8- Now the magic: Calling this code: an example is given in the following (from DosFastConOut fucntion of Dos32):
<code_snip>
/* Save AX and BX */
USHORT AX = getAX();
USHORT BX = getBX();
setBL(DOS_CHAR_ATTRIBUTE);
setBH(Bda->VideoPage);
setAH(0x0E);
Int32Call(&DosContext, 0x10);
/* Restore AX and BX */
setAX(AX);
setBX(BX);
</code_snip>
Here (after saving some registers and setting some parameters for the INT 10h being called), we call interrupt 10h with Int32Call(&DosContext, 0x10); // where DosContext is a CALLBACK16 context.
The call is done "synchronously", i.e. we restart here CPU simulation. The simulation then stops because the generated trampoline code has a suitable BOP_UNSIMULATE instruction.
CURRENT DRAWBACKS:
==================
1- The module which is going to use those callbacks need to know where in memory the code will be placed. Nothing is done "automatically". Otherwise we would have to:
* maintain a (gobal, and finite) table of callbacks (in some way or another), and/or
* be able to place the code in some "shadowed" memory zone of the emulator that gets hidden for all the programs emulated BUT the emulator.
2- Linked to the previous second point comes the problem of trampoline code. It is needed because we need to put a BOP_UNSIMULATE operand after the code to stop the 16-bit code simulation and go back to 32-bit. We need also to call e.g. INT 0x10 from 16-bit to be able to run the interrupt that could be hooked by some program. Some may argue that one can first call EmulatorInterrupt(0x10); but then we would have to find a means of stopping the simulation as soon as the interrupt exits...
3- For calling "regular" 16-bit code (with RunCallback16) we need a suitable callback: "call far_pointer; BOP_UNSIMULATE" .
4- Currently we build the trampolines on-the-fly when calling either RunCallback16 or Int32Call, at the memory location given when initializing CALLBACK16 context. If a given 32-bit module calls some 16-bit code that calls in turn a 32-bit function from the SAME module which calls also a 16-bit callback, then the trampoline will be overwritten. In RunCallback16 (and Int32Call) we save it, push a new one and then call the 16-bit code, and then restore the old one after the call. It seems to work fine currently, but I've found a problem, I think, which is the following:
* Suppose that a 16-bit program calls some VDD function,
* this VDD function creates a thread,
* the two running VDD functions then call back the 16-bit program, or trigger an interrupt from whatever nature which both call 32-bit functions from a given 32-bit module (bios, dos). In this situation many problems arise:
a. Our current implementation of the emulator doesn't support that since you are going to play concurrently with the unique CONTEXT of the emulated CPU... (i.e. flags / registers corruption in sight)
b. If the 32-bit functions (called concurrently, and which are from the same 32-bit module) call some 16-bit code / interrupt, then they are going to use the same memory zone for the trampoline stub and there are very high risks of corruption. A solution for that would be to generate the trampolines once and for all for each registered 16-bit interrupt stub / 16-bit generic callback, retrieve their addresses and store them in some place (that also get shared amongst all of the 32-bit modules of the NTVDM emulator), so that each (possible concurrent) call go to the trampoline and just make the CPU point at it...
Voilà !
svn path=/branches/ntvdm/; revision=62283
2014-02-21 20:31:56 +00:00
|
|
|
USHORT Segment;
|
|
|
|
|
USHORT NextOffset;
|
|
|
|
|
} CALLBACK16, *PCALLBACK16;
|
|
|
|
|
|
|
|
|
|
/* FUNCTIONS ******************************************************************/
|
|
|
|
|
|
2014-09-30 23:47:23 +00:00
|
|
|
VOID
|
|
|
|
|
InitializeContextEx(IN PCALLBACK16 Context,
|
|
|
|
|
IN ULONG TrampolineSize,
|
|
|
|
|
IN USHORT Segment,
|
|
|
|
|
IN USHORT Offset);
|
[NTVDM]
** WARNING! WARNING! WORK IN PROGRESS!! **
** MEGA HUGE IRC SPAM IN SIGHT!! **
Commit a starting point implementation for 16-bit callbacks from 32-bit code that work together with the EmulatorSimulate / EmulatorUnsimulate functions.
That needs HUUUGE reviewing (go to the END to skip details and going to the current drawbacks of the implementation) <-- [TheFlash], Vampyre, others...
How it is intended to work:
1- Add callback.c to the CMakeLists.txt file, and remove int32.c from it.
2- In some 32-bit module that will get called by 16-bit code sooner or later (e.g. bios32 or dos32), include callback.h instead of int23.h.
3- Add a CALLBACK16 MyContext; // definition
4- In some initialization code for this module, call: InitializeContext(&MyContext, custom_segment, custom_offset);
This allows you to define a zone of memory custom_segment:custom_offset that will be used as a trampoline zone. FIXME/TODO: we can return from this call the size of this zone (not implemented at the moment), so that we can know the zone that will be reserved for calls (it will be used in the following steps).
5- Now you can register e.g. 32-bit interrupt handlers with calls like:
MyContext.NextOffset += RegisterInt32(MAKELONG(MyContext.NextOffset,
MyContext.Segment),
IntNumber, Int32Handler, NULL);
Now comes the tricky part: since we want to be able to give precise memory addresses to where to put interrupt stubs (whose addresses will be stored in the IVT) (it's because it happens that some programs expect some few code interrupts to be placed at given places in memory; or one can argue that it is "for IBM bios compatibility"....), we pass a far pointer instead of the context structure as the first parameter. Then, currently the function returns the size of the written code (and it returns too via its last optional parameter).
6- You can do almost the same with RegisterInt16, where now instead of giving a 32-bit interrupt handler, you give the code of a 16-bit interrupt. What changes here is that in the 32-bit case, the 16-bit interrupt code was generated (to call back the 32-bit handler) whereas here you control it fully. For 16-bit interrupt code you need to use IRETs operands.
7- There is a RegisterCallback16 function, which registers at a given place in memory a chunk of 16-bit code. This code is expected to return with RETs. Its accompanying function RunCallback16 is untested at the moment.
8- Now the magic: Calling this code: an example is given in the following (from DosFastConOut fucntion of Dos32):
<code_snip>
/* Save AX and BX */
USHORT AX = getAX();
USHORT BX = getBX();
setBL(DOS_CHAR_ATTRIBUTE);
setBH(Bda->VideoPage);
setAH(0x0E);
Int32Call(&DosContext, 0x10);
/* Restore AX and BX */
setAX(AX);
setBX(BX);
</code_snip>
Here (after saving some registers and setting some parameters for the INT 10h being called), we call interrupt 10h with Int32Call(&DosContext, 0x10); // where DosContext is a CALLBACK16 context.
The call is done "synchronously", i.e. we restart here CPU simulation. The simulation then stops because the generated trampoline code has a suitable BOP_UNSIMULATE instruction.
CURRENT DRAWBACKS:
==================
1- The module which is going to use those callbacks need to know where in memory the code will be placed. Nothing is done "automatically". Otherwise we would have to:
* maintain a (gobal, and finite) table of callbacks (in some way or another), and/or
* be able to place the code in some "shadowed" memory zone of the emulator that gets hidden for all the programs emulated BUT the emulator.
2- Linked to the previous second point comes the problem of trampoline code. It is needed because we need to put a BOP_UNSIMULATE operand after the code to stop the 16-bit code simulation and go back to 32-bit. We need also to call e.g. INT 0x10 from 16-bit to be able to run the interrupt that could be hooked by some program. Some may argue that one can first call EmulatorInterrupt(0x10); but then we would have to find a means of stopping the simulation as soon as the interrupt exits...
3- For calling "regular" 16-bit code (with RunCallback16) we need a suitable callback: "call far_pointer; BOP_UNSIMULATE" .
4- Currently we build the trampolines on-the-fly when calling either RunCallback16 or Int32Call, at the memory location given when initializing CALLBACK16 context. If a given 32-bit module calls some 16-bit code that calls in turn a 32-bit function from the SAME module which calls also a 16-bit callback, then the trampoline will be overwritten. In RunCallback16 (and Int32Call) we save it, push a new one and then call the 16-bit code, and then restore the old one after the call. It seems to work fine currently, but I've found a problem, I think, which is the following:
* Suppose that a 16-bit program calls some VDD function,
* this VDD function creates a thread,
* the two running VDD functions then call back the 16-bit program, or trigger an interrupt from whatever nature which both call 32-bit functions from a given 32-bit module (bios, dos). In this situation many problems arise:
a. Our current implementation of the emulator doesn't support that since you are going to play concurrently with the unique CONTEXT of the emulated CPU... (i.e. flags / registers corruption in sight)
b. If the 32-bit functions (called concurrently, and which are from the same 32-bit module) call some 16-bit code / interrupt, then they are going to use the same memory zone for the trampoline stub and there are very high risks of corruption. A solution for that would be to generate the trampolines once and for all for each registered 16-bit interrupt stub / 16-bit generic callback, retrieve their addresses and store them in some place (that also get shared amongst all of the 32-bit modules of the NTVDM emulator), so that each (possible concurrent) call go to the trampoline and just make the CPU point at it...
Voilà !
svn path=/branches/ntvdm/; revision=62283
2014-02-21 20:31:56 +00:00
|
|
|
|
|
|
|
|
VOID
|
|
|
|
|
InitializeContext(IN PCALLBACK16 Context,
|
|
|
|
|
IN USHORT Segment,
|
|
|
|
|
IN USHORT Offset);
|
|
|
|
|
|
2014-02-26 01:03:14 +00:00
|
|
|
VOID
|
|
|
|
|
Call16(IN USHORT Segment,
|
|
|
|
|
IN USHORT Offset);
|
|
|
|
|
|
|
|
|
|
VOID
|
|
|
|
|
RunCallback16(IN PCALLBACK16 Context,
|
|
|
|
|
IN ULONG FarPtr);
|
|
|
|
|
|
|
|
|
|
ULONG
|
2014-09-30 23:47:23 +00:00
|
|
|
RegisterCallback16(IN ULONG FarPtr,
|
|
|
|
|
IN LPBYTE CallbackCode,
|
|
|
|
|
IN SIZE_T CallbackSize,
|
|
|
|
|
OUT PSIZE_T CodeSize OPTIONAL);
|
[NTVDM]
** WARNING! WARNING! WORK IN PROGRESS!! **
** MEGA HUGE IRC SPAM IN SIGHT!! **
Commit a starting point implementation for 16-bit callbacks from 32-bit code that work together with the EmulatorSimulate / EmulatorUnsimulate functions.
That needs HUUUGE reviewing (go to the END to skip details and going to the current drawbacks of the implementation) <-- [TheFlash], Vampyre, others...
How it is intended to work:
1- Add callback.c to the CMakeLists.txt file, and remove int32.c from it.
2- In some 32-bit module that will get called by 16-bit code sooner or later (e.g. bios32 or dos32), include callback.h instead of int23.h.
3- Add a CALLBACK16 MyContext; // definition
4- In some initialization code for this module, call: InitializeContext(&MyContext, custom_segment, custom_offset);
This allows you to define a zone of memory custom_segment:custom_offset that will be used as a trampoline zone. FIXME/TODO: we can return from this call the size of this zone (not implemented at the moment), so that we can know the zone that will be reserved for calls (it will be used in the following steps).
5- Now you can register e.g. 32-bit interrupt handlers with calls like:
MyContext.NextOffset += RegisterInt32(MAKELONG(MyContext.NextOffset,
MyContext.Segment),
IntNumber, Int32Handler, NULL);
Now comes the tricky part: since we want to be able to give precise memory addresses to where to put interrupt stubs (whose addresses will be stored in the IVT) (it's because it happens that some programs expect some few code interrupts to be placed at given places in memory; or one can argue that it is "for IBM bios compatibility"....), we pass a far pointer instead of the context structure as the first parameter. Then, currently the function returns the size of the written code (and it returns too via its last optional parameter).
6- You can do almost the same with RegisterInt16, where now instead of giving a 32-bit interrupt handler, you give the code of a 16-bit interrupt. What changes here is that in the 32-bit case, the 16-bit interrupt code was generated (to call back the 32-bit handler) whereas here you control it fully. For 16-bit interrupt code you need to use IRETs operands.
7- There is a RegisterCallback16 function, which registers at a given place in memory a chunk of 16-bit code. This code is expected to return with RETs. Its accompanying function RunCallback16 is untested at the moment.
8- Now the magic: Calling this code: an example is given in the following (from DosFastConOut fucntion of Dos32):
<code_snip>
/* Save AX and BX */
USHORT AX = getAX();
USHORT BX = getBX();
setBL(DOS_CHAR_ATTRIBUTE);
setBH(Bda->VideoPage);
setAH(0x0E);
Int32Call(&DosContext, 0x10);
/* Restore AX and BX */
setAX(AX);
setBX(BX);
</code_snip>
Here (after saving some registers and setting some parameters for the INT 10h being called), we call interrupt 10h with Int32Call(&DosContext, 0x10); // where DosContext is a CALLBACK16 context.
The call is done "synchronously", i.e. we restart here CPU simulation. The simulation then stops because the generated trampoline code has a suitable BOP_UNSIMULATE instruction.
CURRENT DRAWBACKS:
==================
1- The module which is going to use those callbacks need to know where in memory the code will be placed. Nothing is done "automatically". Otherwise we would have to:
* maintain a (gobal, and finite) table of callbacks (in some way or another), and/or
* be able to place the code in some "shadowed" memory zone of the emulator that gets hidden for all the programs emulated BUT the emulator.
2- Linked to the previous second point comes the problem of trampoline code. It is needed because we need to put a BOP_UNSIMULATE operand after the code to stop the 16-bit code simulation and go back to 32-bit. We need also to call e.g. INT 0x10 from 16-bit to be able to run the interrupt that could be hooked by some program. Some may argue that one can first call EmulatorInterrupt(0x10); but then we would have to find a means of stopping the simulation as soon as the interrupt exits...
3- For calling "regular" 16-bit code (with RunCallback16) we need a suitable callback: "call far_pointer; BOP_UNSIMULATE" .
4- Currently we build the trampolines on-the-fly when calling either RunCallback16 or Int32Call, at the memory location given when initializing CALLBACK16 context. If a given 32-bit module calls some 16-bit code that calls in turn a 32-bit function from the SAME module which calls also a 16-bit callback, then the trampoline will be overwritten. In RunCallback16 (and Int32Call) we save it, push a new one and then call the 16-bit code, and then restore the old one after the call. It seems to work fine currently, but I've found a problem, I think, which is the following:
* Suppose that a 16-bit program calls some VDD function,
* this VDD function creates a thread,
* the two running VDD functions then call back the 16-bit program, or trigger an interrupt from whatever nature which both call 32-bit functions from a given 32-bit module (bios, dos). In this situation many problems arise:
a. Our current implementation of the emulator doesn't support that since you are going to play concurrently with the unique CONTEXT of the emulated CPU... (i.e. flags / registers corruption in sight)
b. If the 32-bit functions (called concurrently, and which are from the same 32-bit module) call some 16-bit code / interrupt, then they are going to use the same memory zone for the trampoline stub and there are very high risks of corruption. A solution for that would be to generate the trampolines once and for all for each registered 16-bit interrupt stub / 16-bit generic callback, retrieve their addresses and store them in some place (that also get shared amongst all of the 32-bit modules of the NTVDM emulator), so that each (possible concurrent) call go to the trampoline and just make the CPU point at it...
Voilà !
svn path=/branches/ntvdm/; revision=62283
2014-02-21 20:31:56 +00:00
|
|
|
|
2015-10-03 21:47:46 +00:00
|
|
|
#endif /* _CALLBACK_H_ */
|