What Language Is Windows Written In?

[Elliot B.]

Just wondering...

[Jon]

www.grc.com

he writes his stuff in assembly

He writes in the language of assembly, and talks in the language of bollocks.

[smurfiness]

www.grc.com

he writes his stuff in assembly

He writes in the language of assembly, and talks in the language of bollocks.

*LOL* That's about the best assessment of that guy I've heard.

--

Danny Smurf

[macman87]

Microsoft would never use VB for making windows because all VB apps need Windows to run, :D and the apps programed in VB are not very stable. True, microsoft has probably used VB is some crappy app but not with windows :)

[tmeg]

I could've sworn ONE part of Windows is actually written in VB... or at least it looks that way.

Go to the directory %systemroot%\fonts and click File > Install New Font... that dialog looks so old, no?

:D yeah, that looks really old but minesweeper, solitaire, calc and some other apps where not (or only slightly) updated from windows 3.1 as well.... so I think thats only some C code that did not get looked over for more than 10 years ;)

:o Windows is no so big they even don't seem to have the time to polish the whole interface for the new versions.

[the evn show]

If i had to hazard a guess I'd say the old-looking dialogs have something to do with being built against an old version of comdlg. If they used something like version 3 they would have that appearence. Once Microsoft had the font installer working in NT4/95a there really wasn't any reason to update it so they probably didn't waste their time when so many other things needed the attention of their developers.

If you compiled in the vb5 runtime library you're looking at having 10mb executables (vbrun500.dll is 5.5MB when .zip compressed). If microsoft has a lot of .exe files in that range I might believe they were using vb, but last check they had nothing in that range. Besides, if more than one application was written in VB they'd be wasting 10mb per application, not such a good idea.

I do notice a few of the default "mfc" application icons in the windows and system directory though...

[Glowstick]

Dude, you know they wrote Windows 95 in C#, right???

:p

Yeh and they wrote Win3.1 in Eiffel.NET

[Bloozie]

hehehe... :D OOH OOH!!! PICK ME!!! I can write apps in C++#.net.com!!!

[JadeWolf324]

Well..i hate to burst ur bubble..but YES some apps in Windows EVEN XP are written in VISUAL BASIC. Like notepad, paint, character map, and even calculator. these were the first few apps ever. that were originally in Windows 1.0 and were written in Asm, but then when windows got a better gui, and came up with VB, then they took then into the next level. i guess they figure that those programs are good enough the way they are and whats the point in upgrading their code if they work fine in that languge.

[nacs]

Well..i hate to burst ur bubble..but YES some apps in Windows EVEN XP are written in VISUAL BASIC. Like notepad, paint, character map, and even calculator.

Um what makes you think that? Those apps would have been trivial to write in C++ or something similar since they're such simple programs. I'd highly doubt they're written in VB.

[azcodemonkey]

Well..i hate to burst ur bubble..but YES some apps in Windows EVEN XP are written in VISUAL BASIC. Like notepad, paint, character map, and even calculator. these were the first few apps ever. that were originally in Windows 1.0 and were written in Asm, but then when windows got a better gui, and came up with VB, then they took then into the next level. i guess they figure that those programs are good enough the way they are and whats the point in upgrading their code if they work fine in that languge.

Paint on XP is written in C++ with MFC. The others, I'm fairly sure they were written in C. The only thing on my computer I see referencing VB Runtimes is VS.NET.

Spy++ rules. :)

[Glowstick]

Well..i hate to burst ur bubble..but YES some apps in Windows EVEN XP are written in VISUAL BASIC. Like notepad, paint, character map, and even calculator. these were the first few apps ever. that were originally in Windows 1.0 and were written in Asm, but then when windows got a better gui, and came up with VB, then they took then into the next level. i guess they figure that those programs are good enough the way they are and whats the point in upgrading their code if they work fine in that languge.

BULLSH1T ROYAL!

OMFG I swear that you're lucky that I've no special rights here, because I'd f#%&ing ban you for talking such crap!

[Jason]

Windows willl eventually be written with C# with nearly all managed code.

[Glowstick]

With the managed code it doesn't really matter if some parts would be written in VB.NET, since all will be compiled into MSIL. But doing so will make anything but a professional impression.

[|Creeper|]

There's nobody ACTUALLY working at/for MS that could say something like:

c++

Bye.

???

[the evn show]

C# is a runtime-environment language isn't it: if so, writing an operating system would be mighty difficult. If the OS needs the runtime environment to run before it can load, but the runtime environment requires the OS to load before i can run. You'd have the chicken/egg syndrom.

A lot of OS X is written in Objective-C which does require a runtime environment, the core of the OS is still done on standard C++. It will be a very long time (or maybe never) before we see all of Windows done in C#, if not for the runtime problem then for the fact that MS has so much invested in their existing 100,000,000 lines of code that re-writting it all would offer very little return (people are still buying Windows now aren't they?)

[Glowstick]

Longhorn or future Windows' will look like this:

HAL <-> Kernel + Drivers + CLR <-> Managed APIs / Win32 <-> Applications

The core will be native code, the rest managed. Writing a major part in C# is easily doable like this. The whole new API called Avalon is almost fully managed. Win32 is still included for backwards compatibility.

[Justin03248]

C# is capable of writing an entire OS as long the framework is there. If the framework is loaded, it can write to memory and talk to hardware. In theory, drivers and the kernel etc could be written in C#, but MS is not going to do this in Longhorn (because of time).

However, all the upper level code will be in C# (avalon), and it will use DX 9 to draw everything (GDI and GDI+will be extinct). Drawing in DX 9 will completely get rid of the performance problems of C# today on XP because GDI and GDI+ are designed for C++ and they can't talk to hardware. That's why you'll see some drawing slowness in .NET programs on XP, but if you've seen the LH alpha, you'll notice there's no drawing slowness at all with the sidebar (which is written in C# and drawn by D3D 9). The ability of C# to seamlessly talk to hardware through DX 9 is the one reason (I think) that C# will overtake Java on the desktop for user applications.

Oh, and as for the VB.net debate that it's the same speed as C# etc etc cause it goes through the CLR. Well, it's not, because C# can use pointers and talk to hardware. Remember, "unsafe" C# is still "managed." C# also has much more "flexability than C#, especially when trying to completely replace the current Win32s.

Edited April 18, 2003 by Justin03248

[PeterHammer]

I wish some of us in the community would stop talking out of our asses!

First the question is vague. Do you mean windows the CD and everything it contains, windows the OS itself or the win32 API? Windows (the CD you buy) could very well contain apps written in VB (though as Weenur pointed out, it seems unlikely since no APPS that are part of the windows distribution depend on the VB runtimes) or C# (but given C# requires .NET and Windows XP does not ship with .NET, chances are C# is not used either).

The Win32 API, and most of the system libraries that comprise the Windows OS, are written in pure C and Assembler. That is the only way to do it. For practical and performance reasons. Hell even the .NET runtimes are probably written in pure C or C++.

Also, if you know anything about programming then you can tell from how you interact with the API what language it is likely to be coded in. Any time you are passing long pointers to strings (lpstr) or Handles to Windows (HWnd) then chances are that is pure C. You never pass an "Object" in an API call. The API does not understand objects.

For all those claiming all of windows will be written in C# - get a clue! Here are three things for you to think about before spewing out more garbage:

1) When an x86 machine boots it knows nothing about C# or VB or any of that crap. It can understand microprocessor instructions and that is about it. When you install windows it installs NTLDR (IO.sys in DOS and older Win9x versions) on the root of your drive, and writes a small executable to the MBR (master boot record) that can bootstrap NTLDR. You cannot create microprocessor instructions from C# or VB or even Java for that matter. Only fully compiled languages can do that. (NOT That MS cannot change C# to make it compile directly to machine code - but that would kind of defeat its purpose wouldn't it?)

2) If you accept that the Win32 API is written in C (and therefore so are all the system Dlls that support it) do you really think it is worth the trouble to rewrite the whole thing (literally thousands of public functions and probably thousands more that are private or unpublished) just so you can say the whole OS is in C#?

3) How do you think automatic garbage collection will happen in the C# runtimes if it is all coded in C#? Besided the obvious stupidity of the statement (how can you write a language runtime in the language itself) there is a deep problem here: obviously there has to be something deallocating memory in the background - but C# does not allow you to mess with memory. No: for that you need malloc() and free().

Edited April 18, 2003 by PeterHammer

[Justin03248]

"When an x86 machine boots it knows nothing about C# or VB or any of that crap. It can understand microprocessor instructions and that is about it."

That's why the .NET framework could be loaded and the rest of the OS could be coded in C#. It's possible for an OS to be coded in C#, the Framework just must be loaded first, which is written in native code. C# can talk to memory. However, none of this will happen in Longhorn.

However, the entire GUI of LH will be C#, using the native managed DX 9 code to draw everything and get rid of performance problems.

[Justin03248]

Also, remember, C# and .Net are new. MS could very well allow compliling of C# in future releases of the framework to write the underbelly of the OS.

[pctuk]

Can anyone explain what "managed" means? Thanks

[Glowstick]

PeterHammer: Read again what I said, goddamnit!

The ****ing core will be native code and mainly just consist out of kernel, drivers and the freakin' CLR. This allows the major codebase of Windows to be written in managed code very well. What do you think is MS trying to accomplish with Avalon? You get a clue instead!

[Justin03248]

Ya, there's many different "layers" of the OS. C# is usually used as an upper layer language today (although MS could make it do more in OS's after Longhorn). That's the whole benefit of .Net. It doesn't need to get as messy as C++ so you can code more a lot faster and easier. C# just happens to be the super language that can tell the framework it wants to talk to memory/hardware in specific parts of code, so it's the best of both worlds (Java and VB.NET can't do this).

[+Fahim S. MVC]

You guys have heard of the rotor project (.Net for FreeBSD) They (MS) reckon they have all of the functionality that .Net relies on into 2 dlls and the C# compiler, everything else can be compiled from that point using the C# compiler.

Now..... we getting clearer as to the direction MS are taking? or do you want a pretty picture?

ONE!

[PeterHammer]

PeterHammer: Read again what I said, goddamnit!

The ****ing core will be native code and mainly just consist out of kernel, drivers and the freakin' CLR. This allows the major codebase of Windows to be written in managed code very well. What do you think is MS trying to accomplish with Avalon? You get a clue instead!

Chill out numbnut. I was not even talking to you. Your post appeared while I was writing. Its just all the random speculation about VB and then writing the whole OS in C# that got to me.

If you actually read what I wrote, I am just responding to those that read in some half digested news klip something about Avalon and C# and, oh, that must mean the whole OS will be written in C#. That is impossible without full compilation, and hopefully you see it that way too.

And what the hell are you being so loud about anyway. Avalon is still a pipe dream in some architect's head in Redmond and is not planned for release until what? 2005. Maybe 2006 given prior track record. How the hell are you so sure it is going to be all written in CLR languages?

OH I JUST CANNOT RESIST: according to your post the "****ing core" will "mainly just consist out of kernel, drivers and the freakin' CLR".

Wow that sounds like a pretty freaking large core to me. You are only talking about all the software responsible for hardware devices like drives, keyboards, mice, printers, display adapter, sound cards etc... (drivers), all the memory management, CPU process scheduling and process threading (kernel), and then the main API framework (CLR) of the OS too. If you boil down the definition of an OS that could be a whole OS all by itself, and then some.

And let's not forget. There is also the Win32 API - unless of course MS is going to completely throw out all caution and actually produce a version of windows that is not backward compatible with anything before it. Tell me Loud Mouth: Did you hear anything lately that indicates what direction MS will take on this?