At 06:58 AM 4/13/2006, Ken - N9VV wrote:
Dan, did you see the SharpDevelopment activity for C#?
http://www.icsharpcode.net/OpenSource/SD/
de ken n9vv
Dan Hammill wrote:
> [dh] Free Windows Development Tools:
>
> IDE: Bloodshed Software Dev-C++, http://www.bloodshed.net/devcpp.html
>
> Compiler: MinGW, http://www.mingw.org/
> To add cross-platform (Windows, Linux, Mac OS X) C++ GUI development
> capability, add wxWidgets, http://www.wxwindows.org/
>
> * Same code base for native look & feel apps in Windows, Linux,
> and Macintosh OS X
> * Dev-C++ add-in "Devpack" for wxWidgets/Windows at
> http://devpaks.org/
>
There ARE a lot of toolchains out there, some free, some not, some
supporting multiplatform, some not.
A couple issues arise here, particularly for code that is destined for the
"production build", as opposed to fooling around for yourself.
1) The vast majority of PowerSDR users will be running on Windows,
typically the latest version and one back. (i.e. I'll bet most PowerSDR
users are running XP now), so whatever you use has to generate code that
works *troublefree* with Windows (including whichever Service Packs they've
pushed out).
2) Because of #1, I would assume that the "official" release of PowerSDR
will always be built on the MS toolchain (guaranteed compatibility). So,
your alternate toolchain has to be able to either use all of MS's files or
smoothly convert back and forth.
If not, it's possible that you could develop some nifty feature in a non-MS
toolchain, then send a suitable code snippet to someone running the MS
toolchain, have them test it, and get it into the "official build" that way.
3) Cross platform compatibility is insanely more difficult than just having
a toolset that runs on all platforms and has libraries for all platforms,
except for the most trivial of 'form filling' kinds of
applications. Anytime you have timing critical functions or multiple
threads, every operating system does things it's own unique way, and you
either wind up with OS dependent forks, or hundreds of lines of stuff
bracketed by #ifdef. There's also a very different "user model" for Win
vs Mac vs *nix, in terms of how people expect applications to behave.
One of the aspects of the modern trend to SOAP and WebServices type
development is to not only use the ubiquitous HTTP to provide the
interprocess transport, but to try and make the split between various parts
of the system explicit and abstract, which helps with the cross platform
aspect. If your UI rendering engine is a web browser, running on your
platform, it tends to have the appropriate look/feel for that
platform. Yes, one can subvert this: think of things like browser plugins
for flash, and the like, which attempt to make the rendering of your
application browser independent. You've traded browser dependence for
plugin dependence.
