Hmmm... Open Source recognizes VB... but Xbox 360 doesn't?

CorySmith — Thu, 17 Aug 2006 19:16:00 GMT

-- Begin Rant --

Now, I'm not sure what the “real” reason behind a decision (albiet a rumor, but I don't doubt it) of pulling the VB namespace from the modified Microsoft .NET Compact Framework 2.0 that is being done for the Xbox 360. My first question, not even VB related, is why in the world would a company want to create yet another instance of the .NET framework? How many of these things do we really need anyway? I mean, I thought the whole idea of the Microsoft .NET Compact Framework was that it was as small (yet robust) as possible and targetted pretty much any sort of device. I've been told a possible rational for this decision, but still, I'm not so sure I'm buying it. Now don't get me wrong, I understand that it might still be possible to write VB based applications targetting this new framework, except that you won't be able to leverage any of the niceties that are included in this namespace. And, I also understand, that if you really want to target this “device” that you'll do whatever is necessary; even if that means not writing in your language of choice. However, in this case, as I said, I'm not so sure about the motives of such a decision.

To get to the rational that somone suggested... the reason for not including it is because there is a need to have the entire Xbox Live Arcade redist to be less than 50mb in size. OK, sounds great. However, the (according to a folder on my drive at C:\Program Files\Microsoft Visual Studio 8\Smart Devices\SDK\CompactFramework\2.0\v2.0.WindowsCE, the Microsoft.VisualBasic.dll file is a mear 343kb in size. And?!?!?... why is it that these games utilizing this “custom” framework have to redist the framework themselves and hit the end user with that bandwidth (no matter what size this framework is)? Why not just deploy this base framework as part of a Live update and have it exist in the GAC... I mean the 360 is still a windows-based device, isn't it? Sure, it might be different processor spec, but I'm guessing that it's got windows goo in there somewhere, right? Even if this is not the case, it's a closed system... there should be some way to make such a deployment possible. I mean, come on, you're telling me that the game devoloper is responsible for redist (and maintenance) of a framework that Microsoft built that targets the device that they make and maintain through Live updates?

OK, so for the sake of argument, I do understand that not all users of the 360 have a HD (which, I believe was an error in judgement, but that's another story), so in order for some people (“losers“) to download Xbox Live Arcade games, they might be storing these on a memory unit (which, I think, is only 64mb). There's where this magic number of 50mb comes in... cause it sure aint because of bandwidth. ;-)

Even still, let's say for arguments sake that 343kb is just too much for *all* developers to suffer redistributing and the possiblity of a GAC deployment just isn't an option... then why not make it an option? Why alienate, yet again, what at one time (and as I'm told, still is) the largest software development userbase? I mean, there's even the KPL; which is using a BASIC syntax that is mostly about writing games (now, please, don't equate K(ids)P(rogramming)L(anguage) to BASIC, it's just another variation that exists... and, if you haven't looked at it, it's actually kind of cool.).

Now back to the 50mb thing, let's say, for arguments sake that you wanted to go over the 50mb limit. Whether this was due to the 343kb VB namespace (cause your developing in VB) or you just have a lot of content, but it's still not justifiable to deploy using any other model (because Live Arcade is just a great model, let's face it)... then wouldn't it make sense to allow for a larger distribution but with the limitation that it will only be available to Xbox 360 users who have a HD?

Another argument, that I've heard before, is that “there isn't any interest from the VB user base for leverage this tool”. Well, if you continue to alienate, how are any of them supposed to join in the game? Only the most hardcore and determined will do so. And yes, we'll suffer through reading documentation and samples that aren't in our language. We will continue to create our own “communities” to support one another, just as we always have. However, why does it have to be this way?

On another note, because of this, it just fuels more fire for the anti-VB crowd to say that Microsoft doesn't care about VB and VB is dead (yes, I've already been made “aware“ if this latest “argument“; I really don't make this crap up...).

What makes the people making the decision say “Ummm, we are targeting C# since C++ developers are interested in using C# because the syntax is similar.” This, I say, is such a load of crap. If this was true, then what would the the point of continuing development with C++, C++/CLI? And any C++ guy who's jumped into C# (that I've worked with) has said the same thing... C# is just VB with C-style syntax... and EVERYONE of them have moaned about being “managed”. Some of them eventually get the benefits, but many of them resist and say things like “the only way you'll take my pointers is from my dead, cold hands”. VB developers on the other hand have always gotten managed languages... it's the way it's always been (or at least supposed to be, bugs not withstanding).

Like I said, sometimes I just have to ask, what's the motivations surrounding some of these decisions.

-- End Rant --

AddressOf.com : Xbox, Tools

Hmmm... Open Source recognizes VB... but Xbox 360 doesn't?