Move the GET_NEXT_VDM_COMMAND_DATA structure to a global header, and
rename it to VDM_COMMAND_INFO.
Implement BaseSrvCopyCommand, which moves the BASE_CHECK_VDM structure data
into a new VDM_COMMAND_INFO structure.
Implement BaseSrvFreeVDMInfo which frees a VDM_COMMAND_INFO structure and
everything in it.
svn path=/branches/ntvdm/; revision=62374
- Finally get rid of console output handles in the BIOS.
- Move console text buffer copy from BIOS back into VGA memory (~= revert part of r61542), but do it ONLY when attaching the VGA emulation to the console.
- Fix cursor positioning in BIOS & VGA (work in progress).
- Initialize PS/2 after having setting basic console modes.
- Showing/hiding mouse cursor (see the option in the console menu) is done in while() loops to be sure the cursor is really shown/hidden (based on the return value of ShowConsoleCursor).
svn path=/branches/ntvdm/; revision=62373
The RegisterConsoleVDM API (undocumented) allows NTVDM to get a VGA-like text framebuffer hold by the console server. This text framebuffer is unique, per-console (so that changing the active text screen buffer doesn't change the text framebuffer) and exists even if you use a graphics screen buffer.
NTVDM can write in this framebuffer, and when a call to InvalidateConsoleDIBits is done, it is painted on the screen.
Since RegisterConsoleVDM is unimplemented on ReactOS, I start an implementation of this API *inside* NTVDM (that will then be moved to kernel32/winsrv when it will work correctly).
I adapt the code of the VGA emulation to support RegisterConsoleVDM.
svn path=/branches/ntvdm/; revision=62371
Implement a function that creates a pair of event handles - BaseSrvCreatePairWaitHandles.
As already explained in the comments of BaseCheckForVDM (in kernel32), the hParent parameter
is actually an event handle (or more precisely, the client event handle), not a process handle.
svn path=/branches/ntvdm/; revision=62367
Get rid of ConsoleInput handles in the BIOS; setting input console modes should be done in the emulator.c module itself (when setting user interface modes), and if a mouse is present, handle it in the ps2.c module.
Next step will be to get rid of ConsoleOutput handle in the BIOS.
svn path=/branches/ntvdm/; revision=62359
All of the FPU opcodes fetch another byte which is the function number.
This is done by the CPU and it occurs even if there is no FPU attached.
svn path=/branches/ntvdm/; revision=62344
Be able to load an external DOS BIOS file (at 70:0000) and, in case it is the DOS BIOS file of the NT VDM, load the DOS kernel file ntdos.sys when the ntio.sys calls BOP DOS function 0x11 (and put the kernel at DI:0000).
Work in progress...
svn path=/branches/ntvdm/; revision=62343
- Add BOP 0x12 "BiosGetMemorySize" (same number as the corresponding INTerrupt). Needed by ntio.sys when initializing (see next commit).
- Use ASCII names for bios image and dos kernel files names.
- Use the file helper functions committed before for implementing ROM image file loading.
svn path=/branches/ntvdm/; revision=62342
- BIOS32: As a demonstration, load a BIOS expansion ROM (the one I've tested is the "OS in PCI expansion ROM" from: https://sites.google.com/site/pinczakko/building-a-kernel-in-pci-expansion-rom ; we don't support PCI thingies at all, but the bootstrap code works correctly).
- Initialize the BIOS32 stack for the callbacks.
- In the common BIOS functions, if we try to load the Windows NTVDM (SoftPC) BIOS (file: bios4.rom), we immediately hit a BOP 0x00 followed by INT 0x19 (bootstrap to run an OS). The BOP 0x00 is the function used by the BIOS to ask NTVDM to initialize the hardware, the IVT with data and so on. Also we finish to load the low part of the NTVDM BIOS in it (file: bios1.rom).
It's work-in-progress, nothing is done, there are lots of debugging code...
Have fun!
(to load a custom bios you need to put its filename as the first parameter of the BiosInitialize call, in the main() function in ntvdm.c).
svn path=/branches/ntvdm/; revision=62333
- Add utility functions for loading ROM images from files, and running them.
- Add a missing PVOID in the MEM_ALIGN_DOWN macro.
svn path=/branches/ntvdm/; revision=62332
- Reduce the size of the trampoline needed to perform 32 ---> 16 bit callbacks.
- Fix some comments, improve DPRINTs.
svn path=/branches/ntvdm/; revision=62331
- Move an "enable interrupts" command to where it belongs (i.e. in the BIOS32 initialization code; we do it at the very end). Otherwise some problems appears when trying to load 16-bit bios images.
- Use the new macro REAL_TO_PHYS to convert "real-mode" pointers (valid inside the VM only) into "physical" ones (valid in ROS/Windows/whatever).
- Add BIG HACKs (thanks Aleksander ;) ) in EmulatorRead/WriteMemory for wrapping up high memory addresses to low ones, so that we can load bios images (when you start running code at F000:FFF0).
To test 16-bit bios images: in ntvdm.c, put a valid bios file name in the BiosInitialize(...) call, and disable all DOS calls that happen before EmulatorSimulate().
svn path=/branches/ntvdm/; revision=62314
- Fix return values of Fast486OpcodeSahf and Fast486OpcodeLahf handlers.
- [TheFlash], can you please see what we should return after calling Fast486ExceptionWithErrorCode in Fast486OpcodePopFlags ?
svn path=/branches/ntvdm/; revision=62313
- BIOS location must be aligned on 32bit boundaries (or 16, I have to check). This fixes BIOS images loading when they miss a (null) byte to make them (e.g.) 8192 bytes long (example: the BIOS image of windows ntvdm).
- Add useful alignment (and others) macros.
svn path=/branches/ntvdm/; revision=62312
CORE-7932 #comment Silence UNIMPLEMENTED warning for SepAdtPrivilegedServiceAuditAlarm, since this function is called relatively often, spamming the debuglog, and it's missing implementation does not directly affect the behavior for applications.
svn path=/trunk/; revision=62284
** 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
Start to implement EmulatorSimulate / EmulatorUnsimulate (used by VDDSimulate16 and VDDUnsimualte16). This piece of code can be better written, but it works for what I'm going to commit next.
svn path=/branches/ntvdm/; revision=62282
Unescaped use of percent character in a format string causes percent glyph not to be displayed.
Patch by André Guibert de Bruet.
CORE-7934 #resolve #comment Fixed in revision 62281, thanks ;)
svn path=/trunk/; revision=62281
Add a test that checks the ability to link to function and data exports with cdecl, stdcall and c++ mangled names, including forwarders. It just prints "done". Feel free to convert it into a proper rostests, if you think it's required.
svn path=/trunk/; revision=62269
Add another test for non-volatile values. Note that PSEH does NOT work like real SEH here, but this is expected and can not be fixed without special compiler support. Do NEVER DO this kind of stuff inside SEH blocks! Use volatile variables in this case.
svn path=/trunk/; revision=62268
Revert r62264.
Reason: all APIs set the last error when a CSR* call doesn't return STATUS_SUCCESS. If some winetests fail because of this, this is because we do not correctly do what's needed here (normally the TRUE or FALSE value is returned by the console server, and is not retrieved by a success or failure of a CSR call contrary to what's done here).
svn path=/trunk/; revision=62267
- Force the use of memory operands in bit test intrinsics. Bit offsets above 31 (or 63) can't behave correctly with registers (the constant case is fine because it ensures low offsets). Thanks to Timo Kreuzer and Alex Radocea.
svn path=/trunk/; revision=62266
