.NET

[Valik]

Platform SDK has been deprecated for years. With Visual Studio 2005, everything you need comes with Visual Studio. At that point, I only installed Platform SDK for the tools, not the headers or anything. When I installed Visual Studio 2008, it came with it's own version Platform SDK with most of the tools. I realized, the only one I was missing was Dependency Walker. I downloaded it separate and haven't fooled with Platform SDK. So the actual "package" Platform SDK seems redundant at this point.

If I recall, Windows supports loading classes from DLLs. I've never played with this functionality, but if it works as seamless as I think it should, then there's your solution for re-usable classes.

[Richard Robertson]

One thing I find wrong with .Net is the ease of decompilation. Anyone who knows how to read MSIL can decompile a .Net assembly.

[Locodarwin]

Platform SDK has been deprecated for years. With Visual Studio 2005, everything you need comes with Visual Studio. At that point, I only installed Platform SDK for the tools, not the headers or anything. When I installed Visual Studio 2008, it came with it's own version Platform SDK with most of the tools. I realized, the only one I was missing was Dependency Walker. I downloaded it separate and haven't fooled with Platform SDK. So the actual "package" Platform SDK seems redundant at this point.

It's redundant if you're using Visual Studio. If you aren't, it's still pretty useful (headers, libs, if you can use them). My point, though, was that it seems to me the approach for creating new languages and tools for developing for Windows should be to add them through an SDK (which, in addition to being an IDE, VS essentially becomes) and not through a runtime "framework" library acting as a middleman.

If I recall, Windows supports loading classes from DLLs. I've never played with this functionality, but if it works as seamless as I think it should, then there's your solution for re-usable classes.

Like this? http://dn.codegear.com/article/20165

That would be great if we're still interested in runtimes. Which puts us back where we started. Static linking? Maybe. Oversized executables, in that case?

Stroustrup was smoking crack.

-S

[Valik]

It took me about 3 minutes to find the one byte in a .NET DLL I needed to change to make a program think it was registered. I think it took me longer to find out what the hex value of "true" was than it did to actually find the byte I had to change. It's not really harder than reading bad code.

[Valik]

It's redundant if you're using Visual Studio. If you aren't, it's still pretty useful (headers, libs, if you can use them). My point, though, was that it seems to me the approach for creating new languages and tools for developing for Windows should be to add them through an SDK (which, in addition to being an IDE, VS essentially becomes) and not through a runtime "framework" library acting as a middleman.

Platform SDK was necessary as late as VS2003 because some of the headers it shipped with were out-of-date.

Like this? http://dn.codegear.com/article/20165

That would be great if we're still interested in runtimes. Which puts us back where we started. Static linking? Maybe. Oversized executables, in that case?

Stroustrup was smoking crack.

-S

Well, that was just an example to point out that an intermediate language step isn't necessary. Re-usable classes can be provided with existing technology without the need for an intermediate language. Even AutoIt could use the technique described above to call class objects in a DLL.