Codeslinger

Just a random thought on variable sizes: There's an old design decision for programming languages as to whether the variable size for built-in numeric types be static or dynamic. For example, the .NET framework has static sizes: every type in the System namespace (which are all the built-in types) has a size associated with it, eg: Int32. Conversely, in C/C++, int is of dynamic size, dependent on the compiler and the target environment. There are arguments for both. On the static size, you have deterministic size, so you can predict exactly what values will/won't fit. On the dynamic side, you can automatically use the size which is appropriate for the architecture, which gives you automatic adaptability to architectures with new intrinsic data sizes (eg: 32bit -> 64bit) without speed degradation from extra operations to adapt non-standard variable sizes. With those trade-offs in mind, I'd propose a new? thought for variable declarations: a concept of "at least"...

So you're moving from an "old-school" language like C/C++ into a "new hotness" language like C#, and life is so much easier. Memory management is automatic, type information is part of the runtime, everything is dynamic. You can create these very simple expression to perform very complex operations, all auto-magically, and rapidly prototype applications like never before. Life is great, right? Well, there's a small problem which is the 800lb gorilla in the ideology. See, there's two parts to a language enabling you to writing code which does what you want: letting you express what you want to do, and helping you not express what you didn't want to do. The former is aided by higher level abstractions, patterns, powerful expression syntax, API libraries, etc. The latter is aided by strong compile-time checking, API/structure transparency, clear and predictable behavior, etc. A good language balances both of these. The problem with low-level languages i...

So I have a C# object which exposes a COM interface through interop, and it was working. Then I did something, and when I went to reload it, it said the component was not registered. I confirmed that the ProgID was in the registry, and everything appeared to be good. ... It turns out that if the constructor for an object which is being constructed for a COM object instantiation throws an exception, the CoCreateInstance call will return that the component is not registered. This is not normally a problem with native C++ COM objects, since they run the constructor code as part of the registration process, so you'd catch the error earlier. However, C# COM object apparently do not, and the error coming from COM is very misleading. Just an interesting tidbit for COM interop.

So I'm playing with compiling something which is C++/CLI using /clr, and ran across an error while trying to run: 'Could not load file or assembly' of my exe itself! So to make a long story short, after some research, it turns out that: - The .NET framework cannot load assemblies which have more than 65k global symbols defined - Every static string in the code apparently is assigned its own global symbol when compiling with /clr The solution, equally bizarre, is to enable string pooling for the Debug build of the exe. This reduces the amount of static strings dramatically, which allows the assembly to load, and the program to run. Talk about a random issue. Oh, and obligatory "yeah, C++/CLI is ready for real world apps...".

Attributes... simplified programming model, hides the complexity of COM, allows easy specification without obscure syntax, must be a good idea, right? Nope, FAIL. The problem lies in the failure of documentation and ubiquitous support for the other MS libraries. Specifically, are you using MFC (and really, most native C++ Windows programmers probably are, duh)? Sorry, attributing breaks your application. Not that you could tell, since converting to attributed leaves all the other files in the project, and creates new hidden files with the current interfaces. Um... UTTER FAIL. Not to mention the attributes themselves. How do they work? Oh, don't worry about that. Where can I see the source? You can't, it's compiled into DLL's which inject it. How can I see what it's generating? Compile with a special flag, and look for the hidden, undocumented files it might generate. How can I debug issues? Um... online support forums maybe? UTTER FAIL. Nothing pisses off native dev...

So Codejock has done what I thought someone should do, make a generic, all Windows versions version of the Task Dialog. It's not perfect (points off for putting your copy of the structure definitions in effectively the global namespace), but it's pretty good.

This is cool: http://msdn.microsoft.com/msdnmag/issues/04/10/bootstrapper/ http://blogs.msdn.com/chrsmith/rss_tag_Bootstrapper+awesomeness.xml Basically, it's a installer builder for Visual Studio with which you can set dependencies on other modules, which are packaged for the bootstrapper (eg: versions of the .NET framework). When your installer runs, the bootstrapper will verify the installation of the component (including version) you need, and if it's not present, automatically download and install it, before your installer even runs. What's cool about it (versus just packaging in the MSI's for the dependent components) is that you don't bloat your installer very much (bootstrapper is about 500k), but you get virtually the same effect, due to auto-downloading. Very cool.