Are you choosing not to use managed code for any new applications for Win32? Why? Are there resources you need that aren't available from the CLR?
(Note "New" - not enhancements to existing codebases.)
A:
I guess my last reason to write Win32 is portability. C++ compiles on all platforms, simply and without crazy dependencies. So for portable code, I still end up needing to access Win32 for the GUI.
Frank Krueger
2008-12-06 06:03:50
+1
A:
I'm not bypassing .NET to do Win32 programming. I am bypassing both of them to do Java programming since I want my applications to run on as many platforms as possible. Windows may control a majority of the market but I don't see any reason to cut out even small possibilities for profit, especially since I can write Java code much faster than C++ or C# (that's based on my ability, not a reflection of the languages themselves).
Neither .NET not Win32 give me that cross-platform ability at the moment. They may eventually, with Mono, but I still consider that less-than-production-ready and there's still a question over its future in my mind.
paxdiablo
2008-12-06 06:09:24
But how do you deal with the fact that generally java has the worst looking UI's that just don't feel "right" for the platform? Not to mention installing the JVM just isn't as easy as .net, plus it has nagware. (No thank you very much, I don't want to upgrade)
Nathan Lee
2008-12-06 06:55:19
By using SWT instead of Swing. And you can ship the JVM in an already installed state, as a subdirectory of your own code (ensuring you're using your tested version as well), no need to install it, hence no nagware (I'm assuming you're talking about the installation 'pushing' OpenOffice.org).
paxdiablo
2008-12-06 07:05:07
+1
A:
At my workplace there are some old-timers who prefer using MFC because that's what they are familiar with. A few days ago we were to create a simple app and, naturally, they wanted to whip it out in MFC. Only that "whipping out" would have taken about a week and we needed the app in a day. I can't really blame them - old habits die hard. Eventually we went with C# and let the MFC-ers fiddle with the GUI design (which they much appreciated).
Filip
2008-12-06 06:17:53
Not to nitpick, but MFC is a layer on top of Win32. Still, you raise a valid point.
paxdiablo
2008-12-06 06:21:51
I always strugle to understand why programming in c# is considered faster. For the most part I've got libraries of classes to do the networking and such. Why is it faster? Meh.. it's late..
baash05
2008-12-06 06:52:08
We used to have a couple of those guys around at work. I showed them .net one day, and they have never "whipped up" another MFC app.
Nathan Lee
2008-12-06 06:56:57
The .NET Framework comes with many pre-made components, that standard C++ does not have. I mean C++ does not even have a "Date" class. It is also much easier to unit test C# code than C++ code and the GUI designers for .NET make creating dialogs very easy. Win32 resource files are really limited.
Filip
2008-12-06 08:07:49
+2
A:
One significant reason is ease of deployment. I can build a Win32 application (using MFC or WTL libraries), and with static linking there are no dependencies on external libraries (yes, I know that static linking is not the recommended approach).
Users can install and run this application without having to install anything else first: no framework library required, and no DLL hell. For comparison, read these posts from the author of Paint.Net to see how painful it can be for a user to install a .Net application.
ChrisN
2008-12-06 17:11:40
A:
Yes and no. I use C++/CLI if I need to do any Win32/COM stuff. C++/CLI is wonderful. Our UIs are entirely .NET, but occasionally we do have need to use straight C++.
unforgiven3
2008-12-06 17:19:38