So there i was at my VB User's Group Meeting. We had a lecture from a MSFT guy about MSFT's Dev Roadmap.It Appears Microsoft will attempt to Have the Next-Next Version of windows (aka LongHorn) be 70-80% .Net Framework dependent. that means that just above the kernel you will have  Framework standard interfaces which you can access from your code. Also Yukon SQL server in two versions will run and support these internal sytem types, meaning you could basically execute queries wrtten in C# that look for specific files on your system, or have storedprocedures return folder data types. Now THAT i would like to see.

They showed us some early preview screenshots, but of course quickly added reservations saying that "all is still open, it might just be 60-50% integrated with .Net" and so on. i do belive they are going to attempt this dramatic change. everything does point to this fact. Also, i asked whether this would be like the projected "COM" revolution we have seen a few years back, where similar plans had been discussed (or maybe it was just rumors..?) to do the same thing with COM. the answer i got was that the speaker knows nothing about incorporating onto the kernel, but he did mention that a lot of the system interfaces do work in COM, and that somehow this is the realization of that plan(if there had ever been one).

Well, If.NET integration will be integrated ito the OS just the was COM is today, that would be pretty darn disappointing. For eaxample, if i went out to create a File Manager (like Total Commander) with basic functionality, such as viewing files with their associated icons, or displaying associated system context menu of folder and such, and i would try to do all this in VB 6.0,just getting to this basic stuff would be in need of extensive use of API's. Hell, Even in C# i tried doing this and ended up looking at plenty of PInvokes(read: more API's!) articles and extern declarations.

Hopefully, this will not be the case. What do you think?