Zip with source and Win .Net 4 exe. I just decided to public domain'ed the source, can't think of a reason not to and it's easy. Have a ball. 😀
And no promises on the quality this late night hackery, but I'm happy to answer questions if you take the time to have any. 😁
Ok, after a brief break, I've been working on getting dosbox building on windows, following the official looking wiki link - so far "easy" steps but no working results. I'm also dumping the Win31 module exports and working on generating C function stubs for them and code to route calls from the emulation stub over to the windows emulation c code. Hopefully once I have a build setup going I'll have some code to try connecting up. I also need to dump all the imports from and build a list of win3 "simple" exes to tackle first and get a feel for scope of minimal useful emulation. I'm thinking on the order of 100 funcs to start, but maybe some can be stubbed. "The fun part" looks like manually restoring the stack pointer with _stdcall calling convention for each emulated function. I'm not there yet, but I know the emulator side will need message queue emulation and at least simple window management on top of resource loading. It will be interesting to see how much or little we can get away with. I think I'll also need a c/c++ win3 compilation setup to put together some simple test apps... I remember that being very helpful in past emulation efforts. Lots of vague things floating out there waiting to become more specific once the steps are taken trying to get an exe actually working.
So close on DOSBox building in VS2012. Include files all good, compilation completed, just complaining about lib files... 😀 Much easier when not trying to mix ming, etc. with VS instructions, imagine that. Thanks for the great wiki "how to build DOSBox" variety of sites, big help and not too complex after I understood what needs doing.
Today I'm looking for video memory on the emulator side - if possible I'm planing to do GDI drawing directly to 640x480x256 emulated memory without cycling through the emulated x86 side or messing with bank switching. It's looking like VGA_Type > VGA_Memory accessed as vga.mem.linear[addr], and getting access to it from emulated Win31 functions.
If you are using Wine why don't you just let the it's Win16->Win32 interface code do the drawing? That way you'd get native windows.
I haven't looked that deeply at Wine yet, I'll check it out - I thought it translated directly to XWindows. But ultimately it needs to be rendered to dosbox's display; I had mostly thought of that in terms of getting it into the vga screen. I suppose I could create a new display type/subsystem to display directly to windows (or the app as a window? Interesting) but my first reaction is I assume that will be much harder. That design would be taking emulation from dosbox but using wine on the top end? Cool project, but sounds more like making Wine just work on Windows, plus emulating 16 bit code on top of that. But maybe I'm missing something cool? I'm happy to explore the idea in conversation to see if something comes of it if I'm not catching your vision.
I fixed up some bugs in the test app, and now loading and displaying more resources like bitmaps, cursors, and simple dialog layout. Had fun with a test app that used Win1.0 images rather than "normal" win2/3/95 bmps. I'll try to get screenshots and source updates out this weekend. And working on building the dependency world to get DOSBox built, slow but progress. My poor skills maybe, but google wouldn't provide downloads for an ever growing number of "required" .lib files. It feels like one of those trivial problems if I knew the solution, but a slog to get up the curve. "I downloaded the SDL linked, but it wants an SDL2 lib? Oh, I was directed to download 1.x, there's a 2.x, blah blah blah." If someone has a link to the libs, I'd love to just use the existing sdl dlls - that was my original plan until I couldn't link for lack of libs. Otherwise I'll keep going. 😀
wrote:I haven't looked that deeply at Wine yet, I'll check it out - I thought it translated directly to XWindows. But ultimately it needs to be rendered to dosbox's display; I had mostly thought of that in terms of getting it into the vga screen. I suppose I could create a new display type/subsystem to display directly to windows (or the app as a window? Interesting) but my first reaction is I assume that will be much harder. That design would be taking emulation from dosbox but using wine on the top end? Cool project, but sounds more like making Wine just work on Windows, plus emulating 16 bit code on top of that. But maybe I'm missing something cool? I'm happy to explore the idea in conversation to see if something comes of it if I'm not catching your vision.
Wine does display to X11 or Quartz windows but only from the Win32 layer, the Win16 layer calls to Win32 to handle everything. I think it would be easiest to run the Win16 code in DosBox but when run the Wine DLL's outside the emulation which would place the windows outside the DosBox vga screen but ought to be easier to implement.
I can see benefits to that. Wouldn't run in linux, but just use Wine directly, I guess. Might need a translation layer to Win64 at some point, but probably not yet. Nice benefit to have it running "as a native app" look. I'll definitely keep it in mind. I've "just about" got dosbox building, so hopefully I'll start seeing results and be able to experiment within a week or two. ("Or even tonight!" he says with more optimism than is warranted.) I could even do both in parallel and the game would have two identical windows to test it out...
wrote:I'll definitely keep it in mind. I've "just about" got dosbox building, so hopefully I'll start seeing results and be able to experiment within a week or two.
Of course it's your project so do whatever is best for what you want it to be, I'm just throwing out ideas 😀.
I like it, keep it coming as long as you please. It's making me think. 😀 I'd love someone (else) to just make Wine work in windows, too! 😜
I am so close to having Dosbox building, and so eager to get on with this project. Dosbox compiles, and links, and has "missing zlib exports" linker errors, hopefully due simply to link types. Hopefully a bit more sweat and endevouring and I will have obtained that minimum compilable version and can press onward! 😀 Edit: zlib config tweaking and rebuild and those errors went away, now just have a "missing libpng12.dll" error when I've built libpng16.dll; trying to make it happy and want what I've got... So close I can taste it!
Edit:And... success! DOSBox running under the debugger. O Frabulous Joy! Time for bed, but look forward to digging into all the plans now the code has come together.
I have started my DOSBox modding adventure, and of course am starting to have specific questions. Is it better to ask in this thread or start one over in patches or somewhere else?
My first question: as recommended, I've started by creating a callback. If I understand correctly, that will mean I can execute special opcode FE 07 #parameter and get to my callback handler code. But how do I know what value triggers my callback from dos code? And will it move around ever - obviously not, but??? I don't seem to set it up as part of the callback, coding by example, instead it gives it to me:
call_win3 = CALLBACK_Allocate();
CALLBACK_Setup(call_win3 , &WIN3_Handler, CB_RETF, "Win 3.x control channel");
Do I just see what number it gives me the first time, and hope it doesn't change? Sounds weird. But maybe my need to trigger this from a utility program is the problem, and I should build the "start windows emulation and load game.exe" into the shell? Or I could extend CALLBACK_Allocate to request a high fixed number instead of "the first available". Or am I being stupid and I just don't call Allocate and pick my own number? Any thoughts or clarifications?
Hm the deeper I get into this question, the more I just think I pick my own high number instead of/extending Allocate.
I also see an FE 38 "extra callbacks" in documentation, but I assume I'll ignore that. 😀
wrote:I have started my DOSBox modding adventure, and of course am starting to have specific questions. Is it better to ask in this thread or start one over in patches or somewhere else?
I believe things can only be added to the Patches forum section by the admins, so you'll be forced to ask here for the moment, though it might be better asked under the "Dosbox Development" section.
Programs running within the emulation shouldn't execute callback instructions directly, they should call interrupt handlers (or far procedures at fixed addresses) within the emulated BIOS that contain the callback instructions. See callback.cpp where handlers are set up. I think an interrupt handler is preferable because it doesn't have to be at a fixed address, but it can be if necessary.
Specific questions shoukd be asked in the dosbox development forum. Also a working patch should be posted there and will be moved eventually to the patch section. The patch forum is protected from new posts to keep it clean and allow only existing patches threads there.
wrote:Programs running within the emulation shouldn't execute callback instructions directly, they should call interrupt handlers (or far procedures at fixed addresses) within the emulated BIOS that contain the callback instructions. See callback.cpp where handlers are set up. I think an interrupt handler is preferable because it doesn't have to be at a fixed address, but it can be if necessary.
A far proc would probably work better in this case as there will probably be fake dlls loaded containing the callbacks that the imports in the loaded program should point to. That way GetProcAddress with a call far [] would work properly too, otherwise you'd have to have a trampoline with an int instruction.
Thanks for the guidance! And I'll ask future questions in dosbox development, unless I misunderstood that. 😀
Most of these calls are definitely generated by the DOSBox side as fake stubs by the new loader, as you say, as currently planned call it a poor man's fake dll. I was mostly interested in the startup instruction(s) to initiate loading an exe as a windows app rather than a dos app; I'll look at the interrupt list generator code in the emulator and see what I can see to add it there - starting windows as a dos extender interrupt service... That's humorous. I wonder if there is a free and funny meaningful interrupt number to use. Too bad W isn't a base 16 letter, and base 36 MW is 824 decimal, too high. Ah, well, doesn't really matter. I'll see how far I can get with this guidance the next few days, thanks!
...Though, I was initially avoiding changing the exe loader to load a windows app, but there's really no reason to and no reason we'd need to see the "this program requires microsoft windows" headers, which is the only thing I can think of that we'd lose. Then I'd just need the function stubs to call, and they are generated and could be different on each run. That would avoid any need to break the emulation boundary other than via generated stubs; might be easier all around. But in the stubs I definitely have hundreds of separate far calls I have to make, so in the stubs I will need to break the emulation boundary as cheaply and portably as possible, as crazyc says. 😀
@Quadko: It seems your project is coming along good. Hope you keep up the good work. Remember Einstein? Many people called him crazy until he came out with his very first small working app to a friend. Today we all know that as "The Theory of Relativity". Thank you Jesus Christ that good people are eventually understood to do something good for society.
Quick status update: Inside DOSBox I'm now detecting that a requested exe is a Win16 NE file and branching to the new custom exe loader, have the NE header loaded, and am the early stages working through the process of loading segments into dos memory and marking up relocs to internal or emulated calls.
Well, through the holiday season distractions now and hopefully back to this project! Where was I... yes, getting memory and loading the segments, that's right! Hopefully will have some updates to share soon.
