In article <456C865C.17827.2E1983@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
In my case, I'm interested but don't have the skills. I apologise if you thought we weren't interested. Rich does have the skills, so I'm sure he can get ideas from what you have. Jonathan's windows skills have increased by hacking on Winfract, but he'd probably not admit to being a windows programmer. But then Bert wrote Winfract originally with no Windows skills at all, learning as he went.
Oh man! The WinFract author learned Windows as they went?!? Well, that certainly explains some things :-). If you ever want to learn Windows and you're a sequental mass absorber of APIs like me, then give "Win32 Programming" by Rector and Newcomer a try. Not only will you understand everything about how Windows works as a GUI framework, but amazingly enough most of it translates directly to the .NET Framework classes as well. Which shouldn't be a big surprise as .NET is simple a cleaning up of Win32 :-). Win32 is object oriented programming C style -- handles and functions that take the handle as the first argument. Amazingly enough, this is exactly how the driver is implemented in my new fractint code :-). .NET takes all the same concepts but exposes them as real methods on real classes and not funky global functions that take a magic 'this' pointer style first argument.
What Rich is doing is ambitious - he is attempting a full-featured port of the DOS version to 32 bit Windows by abstracting the GUI in a cleaner way.
Honestly I was inspired by what Xfractint had been doing! Xfractint replaces a few low-level routines in order to implement the features it exposes. It stubs out a bunch of other routines for features it blows off :-). I gathered all of that together into one central location and changed all the source code to call into the central location functions instead of the original functions. On the fractint driver, the original functions become the implementation of the driver. Now that I think about it, I'm not sure the 16-bit code will *ever* compile and run properly again because I didn't pay any attention to overlays and crap like that when I added the driver implementation. That probably messed up the segment sizes for the overlays in a way
Rather than trying to hack the entire code (many have tried this),
I'm doing it! :-)
why not start from a known working base and port functions across, one at a time. I use MS Vis C++ version.
Umm... its more connected like a rat's nest communicating through global variables than it is a highly modular piece of code that can be brought over in chunks :-). There is a certain modularity to things, but due to the memory constraints there are a *lot* of really weird memory usage things going on with globals and variables defined in the assembly language for dog's sakes!
[...] A more literal port has it's own challenges, but has the advantage that it leverages the original code better, and if the effort succeeds with the new compile environment, then you have a working feature complete (albeit ugly) program that can be refactored incrementally.
Yes! This is exactly the idea. The kind of "refactoring" I've done so far has amounted to global search and replace of code fragments. Things like "change all calls to mute() to calls to driver_mute()." I don't need to understand what "mute()" does (although its name implies its function in this case) or even what the code is doing that is calling mute() -- I just need to systematically replace all the instances of calling mute() with driver_mute(). Then I implement driver_mute() in the fractint driver by calling mute(). In the Win32 driver, this would ultimately hook into DirectX at some point for sound support. Heck, on an SGI unix box you might have it hooked into the sound support for the SGI machines. (I don't think the X Window System ever incorporated a sound API, did it?) You'd definately want the sound support on an Amiga!
This isn't a debate, because the practical outcome determines if the porting approach works. Rich has yet to prove his port will work :-)
I'm confident that it will work. I am to the point now where I could run it in the debugger and I bet everything would start up just as if you started the DOS version and didn't hit a key. Of course hitting a key on this version doesn't do anything yet, so its not useful either :-). I found out about cygwin/X today, so I can get a nice X server to run on my Windows box and (amazingly!) compile the X11 client on xmission and display on my local box. I did this before when debugging on it, but the X server wasn't that great; I'm hoping the cygwin/X server will be better. At any rate, I'm first going to work on a simple GDI implementation before worrying about the X11 one. I'll be massaging the existing X11 implementation into the driver framework like I'm doing with the fractint code path. I'm not even sure the Amiga code path is really there, it seems to live on in a few #ifdef references in some header files, but doesn't really seem to have an implementation laying around. I'll try to write some kind of porting guide for future ports. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>