The Old Joel on Software Forum: Part 3 (of 5)

Future of Window API

Pardon me for making a somewhat off-topic post to this rather interesting forum.

I program in Xanalys LispWorks, a common lisp implementation. Like most modern common lisp environments, LispWorks has a foreign function interface (FFI). The FFI acts an ambassador between the lisp program and a program written in another language - usually C. This allows lisp to exchange information with a C library. Stable and reliable

One use of FFI is to build portable GUIs. LispWorks has a portable lisp library called CAPI. So I write programs with CAPI on Win32 - the program looks like a Win32 application. Then I take the same program and compile it for Mac OS X and Linux. They will look like native applications (except, usually, some changes to the interface font settings is required). The CAPI lbrary uses the FFI to access native widgets. By necessity, in order to assure smooth porting, cross platform GUIs must be simple.

I must confess that I have not been paying much attention to .NET and C#. My programs use multiple inheritance, can patch running programs with active instances, and customize the object system (using Common Lisp's Meta-Object Protocol). It is unrealistic for me to expect Lisp vendors to produce .NET versions of their environments. Like pushing the toothpaste back into the tube.

While browsing other messages, however, I noticed that there is some uncertainty as to the future of the C based Win32 API. Is Microsoft planning to support 2 levels of APIs? Like Mac OS X has Carbon and Cocoa - will Microsoft maintain 2 APIs as well: traditional C based Win32 and new .NET?

It's just that I am have not been paying attention. (The Lisp world is so cozy). Thank you for shedding some light for my curiousity.

Passer-by
Friday, December 26, 2003

Read the second half of this article, where Joel talks about Fire and Motion.

"People get worried about .NET and decide to rewrite their whole architecture for .NET because they think they have to. Microsoft is shooting at you, and it's just cover fire so that they can move forward and you can't, because this is how the game is played, Bubby."

http://www.joelonsoftware.com/articles/fog0000000339.html

Tom Hathaway
Friday, December 26, 2003

The Win32/64 APIs are going to be around for a looong time, even if they might turn into a translation wrapper on top of a native .NET implementation. There are so many programs written to this API that it would be commercial suicide (even) for Microsoft to drop it.

Chris Nahr
Friday, December 26, 2003

Interesting that Joel says that in that article, because he has recently said that .NET is so great that fogcreek is writing its internal apps with it and will do new development with it eventually.

Wonder if they're writing a .NET => PHP compiler next?

Friday, December 26, 2003

Take a look at http://www.wxwindows.org

It's a C++ API that already has bindings for Python (wxpython), Perl, Ruby, Tcl, and other languages. Check to see if someone did a binding for your Lisp implementation.

Your apps will run on Win32, Mac OS X, Linux, Solaris, AIX, etc...

The only bad part about wxWindows is that the documentation is not quite complete, but because wxWindows is open source, you can always look at the source code to the widgets.

FWIW, I use wxWindows for several commercial applications on Windows and Mac OS X.

jim
Friday, December 26, 2003

.NET might be great but is there really any reason to rewrite quality stuff that works?

Too many programmers, given the opportunity, rewrite old stuff in the next shiny new thing. This is a waste. No wonder offsouring is attractive.

njkayaker
Friday, December 26, 2003

My guess is that Win32 will be completely viable for at least 10 years from now, and people will still be running Win32 apps (perhaps with some kind of emulation) for 20-30 years.

Microsoft has a big vested interest in making sure software written for its platforms has a long life.

Dan Maas
Friday, December 26, 2003

I'm the original poster - thank you for your replies (and especially that "Smoke and Fire" article link).

A few days ago an intern dragged me to this industry dinner where I almost drowned in acronyms. The food was good, but I've been paralyzed ever since. I've been wondering if it is prudent to ignore .NET and whether I should investigate rewriting in a non functional language. I should be doing something productive, but instead I'm going in circles and distracted by this whole thing.

Your replies, however, have helped me break out of this loop. Thanks again.

Passer-by
Saturday, December 27, 2003

Dan,

You sound just like the guys who talked about DOS and 16-bit Windows. Win32 is, for all intents and purposes, just about 10 years old now. How many DOS apps are people running on a regular basis?

Time moves on. This too shall pass. :)

Brad Wilson (dotnetguy.techieswithcats.com)
Saturday, December 27, 2003

That's hardly a valid comparison. The step from DOS to Windows, and to a lesser degree from Win16 to Win32, represented a fundamental architectural change. The .NET Framework is currently merely a wrapper over the Win32 API.

Chris Nahr
Saturday, December 27, 2003

It also happens to represent the only way to take a single binary base to both 32-bit and 64-bit Windows, and still be able to take advantage of the extra memory when it's available.

I'm not telling anybody to drop Win32 for .NET. I'm just pointing out that the incredible statement of "we'll be running Win32 apps 30 years from now" was waaaaaaaay hard to swallow.

Brad Wilson (dotnetguy.techieswithcats.com)
Saturday, December 27, 2003

You'd be surprised how many DOS apps are still out there. They may be running a specialized function on obsolete hardware but it's there. Until recently, we had some reports being run off a DBASE application on DOS. It wasn't worth the effort to port it and then we merged with another company and the whole finacial system was scrapped.

Also, I think our office telephone system or voicemail is running on a DOS box. Maybe it's been replaced, but when the system was first installed it was a PC running DOS. The functionality hasn't changed and I don't recall there being any sort of upgrade. If it's running, why mess with it?

pdq
Saturday, December 27, 2003

Sure, people will run old DOS apps if they get the job done. However, how many people are developing new DOS apps?

Maybe Win32 is soon reaching the point where you'll still run your old apps on it but it won't be very profitable to develop new apps for it.

NoName
Saturday, December 27, 2003

It's not there yet, but it most certainly will be there 30 years from now.

Brad Wilson (dotnetguy.techieswithcats.com)
Saturday, December 27, 2003

By the way, the 30 year comment was meant as a generalization. I don't think IN GENERAL that many if any people are using DOS applications on a daily basis today. Yes, some people, and in some cases, a few select heritage apps are still in use, but certainly nothing above the noise.

Brad Wilson (dotnetguy.techieswithcats.com)
Saturday, December 27, 2003

>>The .NET Framework is currently merely a wrapper over the Win32 API.

Of very import point here is that in the Liunx land, the “wine” project which seeks to emulate/re-produce the win32 api is has made quite large progress.

If any of you have read the story of Compaq and how they came out with a compatible IBM BIOS will know EXACTLY what I am talking about here. Once Compaq FINALLY got a working BIOS, then the whole compatible computer industry sprung from this great event.

It is only a matter of time before much, or a very high degree of the Linux Wine project runs a large amount of windows software via the win32 api compatabile library.

The problem is of course we now have software NOT being written for the win32 api, but now using the .net wrapper. This in effect secures MS future, since new software written will NOT work for Wine. In other words, the wine project is much in trouble, since now new software will requite the CLR.

The above means a much more secure future for Microsoft, as they now can work to protect and own the runtime, and the published win32 api is NOT a threat to MS if other platforms try to run windows software.

I suppose a project to “emulate” or creating a CLR that is compatible with the MS CLR is possible, but it is a heck of a lot easier to extend, or even change the CLR with software updates as compared to the win32 API which is generally not extended that much (and is generally quite stable). The CLR thus creates a moving target as compared to the stable published win32api.

One can argue that the win32 api is not the future, but today, we still use the BIOS that is 20 some odd years old, but we never even give this BIOS a thought.

I think the win32 api is about the same thing (base pc technology), and is going to be part of the computer landscape for a very long time, even if the next generation of developers never sees, or even knows of the win32 api. (just like many new develpers have never seen a dos prompt).

Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
http://www.attcanada.net/~kallal.msn

Albert D. Kallal
Saturday, December 27, 2003

I don't think Microsoft will drop the C API anytime soon. It reminds me of a rumour I had that said that a new version of Solaris was written in Java, white this was completely not true, as the kernel and core UNIX components were kept as purely C programs.

Too many vendors depend on the C API (including Microsoft) and if Microsoft drops it, they can expect to lose a lot of business and customers. .NET is not compatible with C/C++ (as Joel noted) and some people still need the low-levelness of C. (you cannot write device drivers in .NET for instance) What may happen is that new services will only be available as .NET ones or that Microsoft will gradually rewrite some of its programs to be written in .NET. (I personally spoke with one Microsoft hacker who said his team would like to re-write a C++ component of Visual Studio in .NET because C++ causes them a great deal of problems which are a no brainer in .NET).

Shlomi Fish
Saturday, December 27, 2003

.NET on Linux: http://www.go-mono.com/

T. Norman
Saturday, December 27, 2003

Of cousre they won't drop the C API, just like how we can run DOS apps in Windows XP still.

But, eventually the win32 api will become a layer on top of the .NET ... maybe not in Longhorn, but in some future version of Windows. .NET is the platform Microsoft wants to take us into. And while I don't think it's a good idea to rewrite existing apps, it certainly can't hurt to write new apps in .NET (even if for the sole reason of making an easy transition code-wise to 64-bit computing). You youngin's didn't have to live through the pain of rewriting legacy 16-bit code to 32-bit .. ugh!

Yummy
Saturday, December 27, 2003

Are COM(+), OLE, MTS, etc. part of Win32?

They don't look to me as "designed for C". I started that
thread about Future of C as I finally managed to use
IPicture class to display JPEGs from my C app.

So, COM made me do it. Win32 as a platform is new to me,
less than a year, but I already now that COM is 8 years old
or so, and it seems to me that we could see where things
are going looking at COM and related stuff.

And, does anyone now of a book or a site where I could
learn some more about how to use COM from straight C?
MSDN and all the rest of documentation that I have is not
helping much on that subject.

VPC
Saturday, December 27, 2003

Good article on the future of win32: http://www.ondotnet.com/pub/a/dotnet/2003/11/24/longhorn_01.htm

Yummy
Saturday, December 27, 2003

At the PDC the Longhorn people said pretty clearly that the new interfaces (things like the pretty Avalon stuff) were being written for .Net, and it's ".Net all the way down" -- e.g., this is .Net on top of hardware drivers, not .Net on top of the Windows API. The question is whether C/C++ programmers will have a native way to call this functionality (if, for example, you want to add a pretty effect to a "legacy" Win32 GDI app) or if you'll have to use Interop facilities and/or Managed C++, and I don't think even Microsoft has answered this.

Think of it this way. CityDesk is written in VB 6 using some C++ and a lot of Win32 API calls. When XP came out, inheriting the new graphical look and feel was mostly a simple matter of adding a weird manifest resource to the EXE. But when Longhorn comes out, will Microsoft give me a way to take advantage of the whizzy new UI features expected on the platform, or will CityDesk forever look "blah" until we port it to .Net? I'm pretty confident it WILL run forever... I regularly run a DOS application that I wrote in 1987 on Win XP Pro without a problem ... binary compatibility has always been crucial for MS because they know if a new OS breaks ANY existing apps it won't get adopted, period. (See Raymond Chen's recent entries on his excellent blog about the insane trouble they go to to emulate bugs for broken old apps)

Joel Spolsky
Saturday, December 27, 2003

"they know if a new OS breaks ANY existing apps it won't get adopted"

Alas, if only it was this way on the Mac. I am finding several points at which 10.3 is not compatible with 10.2 because Apple has silently changed the inner workings of CoreMIDI. Getting the details is a matter of proding Apple employees on development lists and getting them to admit "oh yeah i changed ohow that works and didn't document it. File a document request bug and if management approves it, some documentation will get made for you showing what changed."

Sigh.

Unhappy Mac Developer
Sunday, December 28, 2003

A bit after the fact, but:

"Alas, if only it was this way on the Mac. I am finding several points at which 10.3 is not compatible with 10.2 because Apple has silently changed the inner workings"

Isn't it?

It's been more than 5 months since 10.3 was released, and I don't know any Mac users who have upgraded. I know Mac users running 10.2 -- it's slower and uglier than 10.3, but not unusably slow and ugly, and they don't see any reason to pay $129. I also know one or two folks still on Mac OS 9 -- it does everything they want and Mac OS X would probably mean buying new hardware or living with a much slower system.

In contrast, everybody I know running 10.0 or 10.1 (and even some 9 users) upgraded to 10.2 within a week of its release.

K.H.
Saturday, March 27, 2004