> > > The Win32 API is quite a > > > PITA compared to something like GTK+ or QT. And that is just > > > the graphics > > > toolkit part of Win32. > > > > Comparing Win32 API and Qt is not really fair, > > MFC and Qt and a better comparision. > > > > I don't have much experience at all with Win32 program > (beyond "Hello World" > with regular Win32 API calls). In MSes defense (sort of) X > Windows has some > pretty screwed up toolkits too. The main advantage of Win32 and MFC is not that they are good, because they are not, but that a lot of people have experience use them and that they are good enough for most purposes. > Fortunately the bad things > can be changed, > or newer nicer toolkits can be written (like GTK or QT) I am not that optimistic, all "toolkits" whether for Windows or X Windows sucks at least to some degree. This is _not_ because 1. The underlying OS/Windowing system sucks 2. The programmers who wrote the toolkits sucks It is IMHO because the expressive power of the language that the toolkit interface has been written in sucks. I do not say that the languages themselves suck, just that they lack the expressive power to model the UI in a good way. There are other languages like Haskell, which BTW Microsoft are funding research for, that can be used to model UI in a better way but using such has other problems. But this is getting off topic. In short, UI toolkits written i C/C++ or similar languages will always suck, if you are comfortable with one whether it is Win32, MFC, Qt, GTK+, GTK-- or whatever use it even if you think it sucks. Learning a new one is seldom worth the trouble you will find that it sucks just as badly or is some cases even worse. Of course if you know Win32 you will benefit from knowing MFC and likewise for GTK+ och GTK--, so I mean of course fundamentally diffrent toolkits. > > Beside most programmers are working with > > maintaining old code and rewriting the code to Qt or > > whatever is to expensive. > > Yes, I understand that, which is why I am never so sure I > really want to get > a job programming. A lot of code was written by bad > programmers, and the > stuff written by good programmers is usually even pretty > crufty because of > all the quick hacks to make it work before a certain deadline. Well, it is your choice. :-) > Anyway.. has anyone else here had a chance to play with Win4Lin? Nope, not me. > With a little work, Wine could probably have most of the > functionality of > Win4Lin. For one thing, the Wine krnl386/kernel32 needs to > be rock solid > (which I am not so sure of right now). For another thing, > GDI needs to be > able to run natively. USER already does run natively, and > the only thing > left is getting all the VxDs right (which is another chore). > > About a month ago I toyed with the idea of a native GDI, and > from what I > have seen on this list, it should be possible simply by implementing a > proper display driver. So does anyone have any objections if > I go ahead and > see if I can hack something out for a DISPLAY driver? Will > more work need > to be done to get GDI to work right (for instance, does GDI > make assumptions > about kernel or the VxDs loaded that simply cannot be > implemented in Wine)? Ulrich is the one that knows these kind of stuff best. Anyway, it has been discussed before and IIRC most people think it can be done. However it will take quite some work to do.
