As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 13 years ago.
I am currently working in a .Net project but from university I have also a good background in Java. Recently I am asking myself, if multi plattform languages (like Java, or VM based like Scala) aren't on the rise?
Lets have a look at Suns WORA write once, run anywhere principle, which had been rephrased to write once, TEST everywhere because in the past especially desktop applications were/are still a Windows domain. But the last years there were quite some changes like
Linux has improved hugely in driver support and usabilty
Mac OS is getting even more popular
native look & feel thanks to SWT/JFace for Java
Rich Client Frameworks (RCP and Netbeans) that save a lot of time and provide rich experience
So, creating applications targeted on multi plattforms should be a reasonable way to go. For example, why should a small/mid-sized company pay a lot of money for windows/mac when it can use Linux (honestly, when you are not a gamer you dont need windows ;) ). And of couse then those companies would prefer software that runs on their machines (maybe the CEO a has MAC because he can afford it but needs the same apps.) Eclipse RCP can provide for example and then it really is WORA.
I like working on C# right now, but in 1-2 years when I want to have my own little company I will use Linux and the development will probably focus on what I've just written. I just wanted to know what others are thinking (maybe I change my mind).
Please don't start a war on Linux vs. Windows vs Mac (I use the first two). Its only about if multi-plattform is a good way for the future, or if you gain more by the advantages of a single platform (special features).
I work for a Qt consultancy company that's been writing multiplatform applications for a few years and I work on KDE's port to OSX and previously at a company providing a client for Windows/Linux/Mac.
The obvious benefits you get from supporting multiple platforms are:
Goodwill from niche communities (including blogging, word of mouth support)
Your developers can work on whatever platform they like so you can recruit them more easily
Your application will probably be slightly less buggy as you'll be testing on multiple platforms
The downsides:
Packaging/distribution/support becomes a big of a pain
Some platforms can get easily neglected
You don't tend to hook into the backend features of the OS as well
If writing a GUI application then you tend to end up with something that doesn't really meet the HIG of any platform unless you have quite a lot of platform-specific tweaking or have a toolkit that helps with this (e.g. Qt)
I still think it's worthwhile and agree with you that it's the future of applications. Really, there is enough good, high-level technologies that there's no need to limit your market to a single platform's users and Linux is a huge in emerging markets so being able to run your application there will be more and more important as time goes on.
Cross-platform solutions I've seen used to good effect:
Adobe Air
C# (with .NET or Mono)
Qt
Java
Web applications (obviously)
Yes, this is happening, but it's a very slow process.
You can trace the trend back to the UCSD Pascal P-system from the early 80's. In the 90's we got the JVM, and in the naughties we got the CLR. These newer VMs each support many languages from third parties. Python, for example, has long had its own VM, but also comes in a version that runs on the JVM, called Jython, and another one that runs on .NET's CLR, called Iron Python.
Other VMs exist that are targeted by multiple languages. The Parrot VM was created initially for Python and Perl 6. The Reia language runs on Erlang's BEAM VM. I'm sure there are other examples.
On top of that, there are many languages that have been cross-platform for a decade or two, like Smalltalk, early versions of Perl, Ruby, etc.
This is all a kind of long-term tectonic shift. It's driven by the fact that computers are getting faster, while many tasks we use computers for don't need to get faster. So, we can use high-level languages to write programs to do these tasks, where it wouldn't have made sense in the past. In the early 80s, the successful new word processors were written in assembly language. In the 90s's, C. Today, Javascript.
Check out mono http://www.mono-project.com/Main_Page if you like C#
Use SWT (http://www.eclipse.org/swt/) if you prefer java
YMMV
If you are going to spend hundreds of thousands (or millions) of dollars developing an application, it makes sense for it to be capable of running on as many machines as possible. Just a few years ago, platforms had many platform-sepcific features, but that distinction is rapidly disappearing with the availability of cross-platform compilers like Mono.
All depends of the activity domain of the software that you develop...
If end users are or plan to use multi-pateform so you must care about it ! If not, you can develop on the plateform used by your customers !
Of course, some peope would say : even if all customers are on Windows, the development is more productive on MacOS... but it's an other question !
In general, your users will generally prefer an app that looks and behaves like a native application. Many of the cross-platform frameworks are really very good at emulating the native look and feel. Just be aware that if your app doesn't feel native (maybe through some quirk in your toolkit of choice), critics will beat you over the head about it forever.
Also, The issue of using cross-platform toolkits really depends on the application domain you're targeting. For example, if you're working with video, creating a cross-platform app with a good user experience is very, very challenging. On the other hand, CRUD (Create-Update-Delete) apps commonly used inside of enterprises are excellent candidates for developing with cross-platform languages/toolkits.
Also, one reason that Java is very popular for applications deployed inside of enterprises is the ease with which you can deploy updates (via Java Web Start - I think C# has a similar update technology too). However, once you step outside of the walls of the business most users will shy away from Java Web Start apps.
Related
I used to be a programmer and unix sysadmin back in the 90's and early 00's. I wrote business software mostly in BBX, which was non-compiled, procedural BASIC. It was all text based when I started, and I only just got into GUI and OOP with ProvideX by the time I got out. I did do some SQL work and understand basic database concepts.
I've continually dabbled since and tried to keep up by running my own Debian web server here at the house, doing little script programs here and there, and most recently learning PHP and Python. But I would like to get versed in the current state of the industry and hopefully make myself employable in it again.
My current learning project is to write a db app that I can use when drag racing to log run data, report based on various combinations of variables, and predict vehicle performance. This should cover IO, data management, and some complex math. I do want to make is sellable, so it has to be in Windows since all other racing software is. My two options now are to write it in MSAccess, which isn't really programming, or to write a front end in Python and use MySQL for the data.
I assume I should go the Python path out of those two, or should I choose a third path that would pay more dividends toward a job? My biggest concern is wasting my time learning pointless stuff. I assume most of the work out there is db related and web based applications, so that would be my ultimate goal. Correct me if I am wrong on that.
Thanks for any input,
Dave
If your goal is to get back into software development, then I recommend that you first ask yourself what type of industry and development setting you'd like to work in. Learn something about the skills those industries are demanding... Then hit Monster and peruse the job qualifications for companies in those industries. Don't limit your view to just language names and broad job descriptions either, but really try to get an idea what sort of developer they're looking for and whether you'd fit in well.
You will be able to find many interesting technologies in lots of different business domains, but what do you really want to be working to help deliver? Python coding, for example, may be interesting, but I'm sure you'd be more interested if it were supporting your motorsport interest in some way versus, say, baby food. When you have the business domains narrowed down, then you can focus on the background required to get jobs in those industries.
You will find an endless set of recommended "hot" techologies if you search for them. I'm sure you can find a list, or post, which will confirm any bias you have on what to learn. But chasing the technology of the day may lead to an unfulfilling day-to-day job if what you're applying it to is not something you find interesting.
I would say that the answer depends on what type of job you want to do. The Fortune 500 company I worked at last summer had everything from mainframe c and cobol, java EE, .net to ruby on rails and python in applications. There are still alot of jobs maintaining legacy desktop applications. But the web atmosphere is obviously the future of business computing, and java EE and .NET are huge players in that arena. As for the project you are describing. I've done QT applications with python and there are python libraries for GTK that I've seen used to run apps in Windows. I've also used java swing and awt to build graphical applications and other than the learning curve for the layout system it works really well for building applications. I wrote a really basic windows application using visual studio and C# one time and that seemed to me to be very easy to write.
Enterprise level Java or .NET involve a fairly steep learning curve, so I would have those as a medium-long term goal rather than try and learn that tech immediately.
It seems to me that learning a high productivity web framework is the best way for you to go. "Ruby on Rails" seems to be a hot ticket at the moment. I've only had a small look at it, but it seems pretty quick and straightforward. Your drag racing app would be a good place to start.
Build a couple of websites for yourself using the tech. Then build a couple of websites for friends for a nominal fee. After that, see if you can find a real client (perhaps a local business). If you have 2 or 3 of those under your belt, then a potential employer will at least take notice.
One warning, though - people expect web sites to look nice. If you don't have good interface design skills yourself, it will be in your best interest to hire a designer to pretty up whatever you produce.
For a Windows desktop application, you can use C# and the various .NET APIs, and store your data in either a Microsoft-provided database, or SQLite, which is a reliable, server-free SQL implementation. (I don't know anything about Microsoft tech, hence the vagueness of my answer.) There is a lot of work available using C# and .NET, and it should be easy to pick up. You'll meet less resistance on the Windows platform with Microsoft's kit than with third-party languages like Python.
I have been planning to build a Dentist Application for the use of the Dentist to add patients(with medical profiles...), organize visits, manage balance/fees....etc
I know Java, .NET( C#) (some windows forms), and Python. Do you have any suggestions with the language I should maybe start with and the framework and IDE that will make my life easier (and help me finish in a good amount of time). This program will be connected with a database of at least 1000 patients...
IDE's I am familiar with : eclipse, Netbeans, and Visual Studio.
I want suggestions with reason explanations (why would you favor C# over Java ....compatibility....etc)
Thanks,
It's not the database side, or even the programming environment, that will be the issue for a dental practice.
I consult for a dentist friend of mine, and the opportunity arose to sell him a fully-functional contact/document management application to run his patient database.
In the end, I couldn't in good conscience recommend my own application, because not being designed for the dental sector, it lacks the specialised interfaces with dental imaging systems.
Databases, appointments, invoices, etc, are easy.
But what a dentist needs is something that integrates with the dental records themselves - the X-ray images of teeth. It needs a simple UI, easily usable by the dental nurse while she works with the dentist while he has his hands in the patient's mouth.
We could have written a suitable graphical interface to an image library (imagine a diagrammatic representation of the teeth in their relative positions in the mouth, linked to the images themselves), but it wasn't worth it - especially as there are several highly specialised dental packages around already.
I suggest to start with some research on the subject (the dentist domain) and to make a decent functional design before you start to think about IDE's and languages.
And then try to figure out some other things:
For instance, will you make a SAAS or a windows client, do all your customers have internet access. Iis the sensitive patient data allowed to be stored on the web.
I believe that question is very relative to the person programming. I think as the developer you have to figure out where you would be most successful at or what you want to get out of the project. If you are using this project to make money then do what you are comfortable with. If you are using it to better yourself as a developer then pick a language you are less confident in.
The one thing I want to add, is remember PHI (Protected Health Information). So, you have to have patient privacy in mind when building an app like this.
If it were me... I would write something in .NET and use Visual Studio which works very well for windows forms. Windows forms would work very well in an office environment.
Just my 2 cents.
First introduce yourself to the business knowledge. Healthcare programs aren't written overnight and you have to take into account that you need to have a very secure application and probably also need to keep years of information (the program I was involved in in 2001-2002 had to keep 30 years of patient history due to Belgian law).
Choosing the technology is actually entirely up to you: what are you good at? Can you find already prebuild pieces of code or controls ...
You can write such an application in any of the languages you have mentioned.
Research the features you will need and the support you can expect from each language and the different available libraries.
You need to come up with a good design first (regardless of language/platform), and make sure you have all the requirements - how many people should be supported in the system, how many concurrent users, privacy of data, security features, access patterns etc...
You should probably use the language you are most comfortable with, in particular if the features you require have similar support in the different languages/frameworks.
Let me introduce myself a bit.
I have 7 years of C++ (most MFC) experience, 1 year C#.NET and 2 years Java experience.
I know little about web application, what I did and am doing is Windows desktop applications.
I start to do some (minor) (freelance) side projects in the past half year and uses C# mostly as it's more "rapid" than MFC. But seems there's more web projects in this market than desktop projects. And I do not feel good as long as I do not know web development.
So, should I touch the new web filed for me or just stay focus in desktop application but learn more e.g Python, or Frameworks/Libraries such as Qt or Boost?
My gut feeling is that more and more people/companies are moving their projects to the web. My company, for example, has added numerous web applications since I have been there. Another prime example of this is Microsoft (yes, even them) providing a web-based version of Office, their flagship product.
There will always be a need for desktop applications, but I see more web-based projects in the future. It's always good to learn something new, anyway.
EDIT: Oh, and you don't lose anything by being aware of "desktop-based" processes. You may be doing more server-side programming, even if it is web-based. So, in other words, it doesn't hurt to continue expanding your knowledge in that arena, as well.
There will most likely still be a market for desktop applications for many years to come. However, web development seems to have taken over a large share of the development market from what I can see. I would recommend definitely getting familiar with web development as it definitely can't hurt to increase the number of skills you have even if you never stop writing desktop apps.
Since you have experience with C# you might want to consider doing some ASP.NET work. Or if you feel the need to learn a new technology then maybe consider a framework like Ruby on Rails.
I'd really suggest looking into web development - like you said, there are many more web application projects - and you already know C#.NET and Java, and both of those languages have really good API's / frameworks for web development. ASP.NET for C# and Java Servlets/JSPs.
I'd first suggest learning some really basic HTML to learn how pages are rendered, then try to make dynamic versions using the language of your choice. Then I'd learn some other web technologies like CSS/Javascript/some Javascript libraries - then I'd start looking at frameworks that build on top of the basics in the language of your choice.
Oh, and some further suggestions - there are web frameworks that are component-based rather than request-based - you may be tempted to learn these as a shortcut to web development since most claim that developing in them is similar to desktop development. I really wouldn't suggest this - as in practice you really do need to know how the web works at a lower level to develop custom components, include things that the framework doesn't do, or to debug them when things go wrong even when using these frameworks. If you jump right in you can get lost/confused pretty quickly.
Microsoft Office 2010 will have an online version. To me this is a watershed moment for Web applications. Office apps are an important litmus test as once you can do Office on the Web (which has been the case with Google Documents for some time but Office has important symbolic meaning) you can do most things that most users care about.
Desktop apps won't die but I definitely think they're going to take more and more of a backseat.
I'd highly suggest you read How Microsoft Lost the API War if you haven't already. One of the things that's particularly amazing about this post is that it was written in 2004.
I honestly believe that with maybe the exception of OSs and browsers, everything will be a web app within the next 10 years. Having said that, let me clarify that by everything I mean everything that a) involves a UI of some kind and b) can be guaranteed secure.
User-interfaced apps will always at some point need a backend, which will at some level require code that is not being interfaced by humans and not being executed via HTTP. I am always reminding myself that things like 'cat' in Unix are actually programs that the OS is calling, not just a function built into the OS. MySQL won't be a web app (as far as I know), but app that powers web apps. We may get to a point where these apps are fully developed via a web interface, written, audited, uploaded and called all via a browser, but at some level its still running behind the scenes.
On that second point, about guaranteed security, I can very easily imagine a large corporation or government office running 95 percent of their daily routines via web apps, but mandating that certain high-security operations be done on a machine directly interfaced with some sort of mainframe, after passing through the cool doors with the retinal scans and what not. Or simply because they can't risk moving certain mission-critical apps over to the web, from fear of it breaking our losing data in the process.
But with those two things aside, I honestly believe everything will be web-based. With the advancement of Web Services and XML in general, it will be possible to not only access and interact with our data, but to plug our custom apps into another app and extend that interaction further and in any environment we want.
It's like that Apple ad "There's an app for that." Except once people get the real picture, it won't be an app written for your iPhone, but a URL. "There's a site for that."
I recommend learning the Lift framework. It's as easy to use as Rails, and it's based on a statically-typed language for the JVM, Scala. From the perspective of your background, Scala should be middling to easy to learn, and you'll be more likely to be comfortable with it than with a dynamic language.
In my opinion, you have a good chance of picking it up quickly, learn a lot about good practices in web development, and even expanding your programming horizons a bit.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
When you are considering an upgrade in a development tool, how important is backwards-compatibility to you? Would you still purchase Visual Studio 2010 if it required significant changes to your source code? Where is the tipping point for you in terms of trading backwards compatibility for new features?
While you asked this from the point of view of the developer, I think it would be a more interesting question in reference to the software you develop. So I'm going to answer that question instead. :)
Hardware and software that's backwards compatible (and, more importantly, future-compatible) provides a sense of security to your users, especially when buying or upgrading platforms like Windows. If nothing else, Windows is known for its meticulous attention to backwards compatibility. You can run programs written over a decade ago on Windows Vista with only minor problems, provided they were "well written" (i.e. don't use undocumented APIs).
On the other hand, strict attention to backwards compatibility can tie your hands when you're attempting to introduce new features or to revolutionize the platform. Apple knew it had a dying OS, and in one of its most daring moves, it purchased NeXT and decided to make NeXTSTEP the new MacOS. One of the key things that sold people on the transition was the backwards-compatible layer Classic. Again when Apple decided to switch to Intel chips, a mechanism for running PowerPC apps on Intel called Rosetta, along with the Universal Binaries, allowed people to freely move between PowerPC and Intel without fear of application loss.
One interesting thing is that with the transition to Intel the Classic environment disappeared, but nobody really cares because they had the preceding 5 years to transition away from Mac OS 9. So it is possible to eventually drop support for legacy systems as long as you have an easy way to migrate to the new system and give your users ample time to do so.
In a development tool, if it doesn't provide total backward compatibility with my previous code, I won't buy it and I doubt anyone would. Frankly, there's no point. If I already have a compiler that works to build my source code into executable code that works for me, then I'll use that. Why bother changing my code to conform with what is obviously to the toolmaker not a standard? If they force source code changes from one version to the other, why would they bother to make the next version compatible?
100% backwards compatibility with source is a requirement. The only situation where this isn't a total requirement is when the incompatible bits are extensions; i.e. API changes that are specific to the tool, such as Eclipse plugins, etc. Even then, I'd like compatibility, but I realize that it can't be completely expected. But if you provide an API for base application / tool development, and can't be bothered to maintain compatibility; well, then, you clearly aren't serious about your tools, and I won't pay serious money for them.
For home projects, backwards compatibility really isn't important. For the office/enterprise, it's absolutely critical.
It depends on what environments you need to support and what third-party tools are used that may or may not be compatabile.
For example, where I work we upgraded everyone to VS2008 from VS2005 except for our BI group as the SQL Server BI tools were not compatible with VS2008. Once they were updated, they upgraded to VS2008.
When looking at VS specficially, keep in mind that VS2008 can target .NET 2.0, .NET 3.0, and .NET 3.5. The trick is to realize that it actually targets .NET 2.0 SP1 and .NET 3.0 SP1. As such, upgrading the IDE should not require you to make changes to your code.
In genreal if you are developing a platform which will be constantly used by a lot of other users to build their own products, and you plan to develop the application for a long time then it is important. See the PHP, Python, Eclipse and other open source projects who put a lot of importance into backwards compatibility. It is also importan when developing services or other open apis used in the n-tier architecture. You can have all applications in an enterprise breaking all the time when you change your services.
Now, If you are building a shrink wrap application or a bussiness application then it is not so important, beacuse each version is separate from its predecessors.
Since lot of changes are happening in the Software and Hardware field, I think it is a good idea to be open for new changes and better tools while you architect your solution. For example we didnt have multi core processors and high end graphics cards or network card back in 90s, So naturally the optimization goals of the compilers and tools were different. But at the same time Visual studio like tools are doing their best to accommodate the old frameworks and apps.
I think if we are looking forward for a better world, we should be open to a constant change until this industry is super matured. (May not happen in our life time though :) )
Define "significant changes". I'd go for it if the changes could be made with a carefully crafted "search & replace" even if they were extensive.
However, that's what I would do. Any company I've worked for would balk at any changes to existing code.
What are the compelling features of MFC? Why would you select it for a new project?
MFC was a good option 10 years ago. It is still a good wrapper over Win32 API but unfortunately obsolete.
Qt is a better option with one big advantage - it is platform-independent. With MFC you're doomed to Windows.
I still use MFC for all kinds of applications. MFC got a bad rap from it's early implementations, but it is excellent now. I find it quite a bit more convenient than WTL as well. Plus the GUI tools in Visual Studio are already setup to make it easy to rapidly develop GUIs with MFC, mapping controls to variables, DDX, etc.
For desktop applications that I intend for wide distribution I still go with native Windows applications, usually in MFC, because we're still not at a point where you can depend on your customers to have the version of .NET that you'll be using installed and asking them to install it will cause you to lose sales, not to mention the customer service headache when they run into problems installing .NET as a result of trying to get your app to run.
The advantage of MFC is that it's still nicer than coding to bare win32 and you can distribute a native .exe that doesn't require a 23-50Mb runtime like .Net.
Now, if you're concerned about those things there are better alternatives out there: C++ Builder, WxWidgets, etc. But some places won't consider non-Microsoft tools.
You could sort of reword the question, why would you select C++ over C# for a desktop app. C++ still offers speed advantages which matter for some applications (I work for a company that creates software for electronic trading. Speed matters a lot).
If you are going to develop a desktop app aimed for Windows only in C++, then MFC is the most mature choice, with lots of free code based on MFC on the internet, lots of knowledge.
Apart from win32 api itself, MFC is the only mainstream Windows programming technology that is still alive and well in 2011 after 15+ years. Back in 2001 everybody said 'MFC is dead, it's all Winforms now'; in 2005 everybody said 'MFC is dead, it's all XAML now'; now it's 2011 and Winforms and XAML are dead (OK XAML maybe not really dead, but way past its prime) and MFC is still being updated with the latest developments (ribbon, Aero extensions, Win7 API's etc).
Of course, that doesn't guarantee anything for the future, but over those 15+ years, a lot of MFC code written, and it will remain in use for the next decade or decades. It may not be the prettiest tech but it's well-understood (its good and bad points) and is not a moving target like other hype technologies are, meaning that people who actually want to get stuff done can sort of rely on it (well more than on the alternatives, anyway).
(same goes for C++, btw)
Here's a possibility - imagine an application that would require a large amount of memory, say a graphics program, a game or maybe some high performance business application. It's no secret that .NET applications hog memory - in such a case, you may want a lean MFC app for the core of your application. You can always load up and use .NET components, controls, etc through either COM callable wrappers or directly through C++/CLI.
That all being said - MFC is a pain. Consider WTL instead - you can still call into .NET if you need to, the same way as I mentioned above for MFC. WTL is a lot nicer than MFC :-)
Apparently it is still a good choice for applications for windows-based hand-held devices, such as point-of-sale devices. In these, resources are limited so things like memory management become more significant.
Quick Tour Of New MFC Functionality
I hear they have a new ribbon control. If you're into this sort of complexity. Here's a screenshot of a newly generated app:
(source: msdn.com)
Really, it's just a widget update. So do we need more widgets?
The existing windows API is entirely C based. If you want to use C++ (and you probably should) then MFC is the logical choice if you wish to stay native (i.e. not using .NET).
MFC is just a set of object-orientated classes over the top of the C API. Plus quite a few additional "helper" classes that make it easier to do everyday tasks.
I think not.. MFC would lose out in
Level of abstraction
Development Time
Troubleshooting time
Learning curve for new developers
Future proofing (although now that's questionable.. with something new coming up every 3-4 years)
Finding good people who know their MFC
Easy to use controls
The only place where MFC would probably sneak past is if you have some very performance intensive applications like you have things on screen that need to be redrawn every 10 msec or 1 sec. "Managed" apps still haven't managed to jump past that hurdle.
MFC was an important step in the evolution, but now better options are available.
On design & technical merits alone? Sorry to be categorical, but none. It's a poor design, a hugely leaky abstraction where you have to fall back to Win32 API programming, misuses C++ egregiously, and is firmly targeted on yesterday's technology: you won't get a modern (or even an attractive!) user experience out of an MFC app. If you can get C# developers and you don't have serious hardware limitations, go with WinForms.
External factors such as the availability of competence for hire, training programmes and third party components, on the other hand, can still extend its lifespan, at least for some kinds of applications: small & simple, targeted for special applications with reasonably few users, preferably in-house.
If you are developing Windows CE and mobile apps in C++, as Einar has already mentioned, MFC is a good choice. If you make this choice, MFC then also becomes a reasonable choice for the desktop as you can use the same code across desktop and hand-held devices. MFC remains a good perfomance / easy to implement combinitation in this scenario. Personally, I use MFC in conjunction with Stingray libraries in these enivornments which gives a very good interface, good performance and is quick and easy to implement.
I would say that speed and footprint are good reasons over .NET.
It's probably true that you'll find it difficult to locate good MFC programmers, but thats just as much because the modern languages promote lazy programming techniques and most programming courses gravitate towards them as they are easier to teach.
I've written cross platform code for years so when I need to write something I always have a very thin abstraction layer between it and the system calls for almost everything except posix calls. That way you can code it go MFC but quite easily convert it a different API later if needed. My base set of c++ libraries that I use for everything does this with a small System class. I currently have it using MFC for Windows and I also have it using XWindows for Linux and a native Mac version as well. And later on when I port it for a handheld it should be quite painless.
If you want to take a peek, it's LGPL'ed and is at:
http://code.google.com/p/kgui/