Basically "Multiple windows are a pain, since I'm using raw Win32 I have to do all the window management by hand." sounds like some bull-headed excuse I would come up with. It seems that a more practical approach would be to use one of the many frameworks out there to deal with the crud of managing windows and dialogs.
I'd rather use MFC than one of the third party window managers. My request for additional details was not a request for potshots, but a request for why you chose that particular one. My time is limited: I can spend my two free days a month on updating the window manager to something slightly more modern so that you can do something that you can already do, but slightly more easily, or I can work on the broken timing system which is holding back all the other improvements people need. As an example.
I have this argument with a friend of mine almost every day. He has embraced "technology" (.net mostly, but other development solutions as well) and sells a successful billing software that supports his family and gives him all the free time he wants. As for me, since I have a mental block to anything other than doing it the absolute hardest (albeit fastest and most efficient) way, but I don't have anything I'm selling and I still work a day job for someone else (an employer).
Not quite sure how this applies to my desire to prioritize the code I work on.
You are always pretty practical, so I figured you would find a cross platform window manager / framework and get on with making the emulator better... Maybe you are more stubborn than I thought.
It's a Win32-based emulator -- how the heck would porting it to a cross-platform window manager help? Are you arguing my point that I don't currently want to spend time creating all the code to support new windows, or my dis-interest in porting to other platforms? Your quote suggests the former.
Unlike many projects out there, I test my code. If I want to support other platforms, then I need to test or arrange reliable testing on those other platforms as well. It's not something that I am currently interested in doing. Nobody is supporting my family through Classic99 nor will they ever, thus it does remain lower priority than things that do or may.
The thing you seem to be forgetting in chewing me out here is that I do Classic99 because I like working on it. I do the odd request because I'm glad that people like using it. But it is not supporting me by any stretch of the imagination, and it's a long way from being my only spare-time project.
As for the license of wx, I don't know. I don't think that just because you *use* some LGPL software that you have to also release using that license. I think all you would have to do would be to include their license notice that acknowledges that you are using wx. Using GPL stuff does not prevent you from making closed-source commercial products, or anything in between. I could be wrong though, since I never got a project to the point where I needed to worry about it.
I think you should spend some time reading the licenses, and less time guessing. Facts over theories.
GPL absolutely prevents you from making closed-source commercial projects - in fact that's its entire point. LGPL is only slightly more permissive. If you include any code from a GPL project in your program, then that program must also be licensed as GPL. One of the strongest terms of GPL is that anyone who receives a copy of the program must also be able to receive a full copy of the source, and be licensed to distribute that source and object code as they like so long as they also license as GPL. LGPL permits specific exclusions.
This means that I can take any GPL package, repackage it, strip author names if I like, and call it "TursiTron". I can then sell the package for $5000. But everyone who buys a copy from me is entitled to the source to TursiTron, and likewise they are free to then give it away for free if they choose. I don't like GPL for most of my code.