The BigSoccer Longhorn Information Thread

I'm looking forward to this release. I'm pestering my boss to buy MSDN Universal for me so I can play with the Beta version when it starts shipping on MSDN.

 

I won't be getting Longhorn for a number of reasons:

1) In early pre-beta releases, the testing/reviews have indicated that Longhorn runs "sluggishly" on a system with a gig of memory and a 2.4 GHz Pentium. I can't tolerate an OS that is such a resource hog. It will probably get better by the time of the new release, but I'm sure it will still require high powered machines on which to run.

2) Longhorn has an entirely new 3D GUI library, nicknamed Avalon. The .Net runtime engine is also embedded. And with this, the classic Win32 API will run in emulation, which will undoubtedly break an ocean of existing applications (which are built upon the Win32 API), and the ones that aren't broken will run sluggishly (as is usually the case with emulators). The 3D stuff might look cool, but it won't necessarily make the computing experience more productive, easy, or useful. And I don't want the extra performance hit, nor do I want to be forced to upgrade other software in order to make them run on Longhorn.

3) The new WinFS (file system) is based on database/XML architecture, as an extra layer on top of the current NTFS. The idea is that it will allow you to find stuff more quickly, like old emails, etc. My reaction is that I don't want an extra layer of resource hogging bloat and potential bugs for the purpose of making it easy to find stuff that is already sufficiently easy to find.

4) Security - MS still needs to prove that they can solve Windows' gaping security problems before I'm willing to fork out more money for a new version of Windows .

5) Privacy, or lack thereof. DRM (digital rights management) is going to be built into the OS, so that big brother MS and it's partners can watch everything you do with your PC (even more than now). It will also restrict you from making "fair use" back up copies of CDs, DVDs, software, etc. I have nothing to hide, nor do I copy/post/share someone's IP/music/movies etc (I have no need or desire to). But, being the honest computer user that I am, I don't like being treated like a criminal by the company that is receiving my purchasing dollars. Nor do I like to be deliberately restricted from doing things that I may or may not want to do with my computer. Besides, the true pirates out there will easily crack this stuff, so MS will only harm it's honest, paying customers.

6) Draconian Licensing - Unless MS eases up on their licensing terms, I don't want them to get any more of my money. I don't want to have to pay for another license, or get another product activation code, if I upgrade my hardware.

7) Pricing - MS needs to bring down it's pricing. I can get alternatives that are more feature rich, more reliable, more secure, and more user-friendly for a fraction of the cost.

8) The new Longhorn features are already available in the market, in one form or another. 3D graphics are already available in video games, and in Sun's Project Looking Glass. Journaling File systems (which are very efficient and allow easy finding of files) are common place. The .Net runtime is already available, and the Java Virtual Machine (and the Java Language) is already available and mature. Longhorn is also copying stuff directly from MAC OS X. In other words, what Longhorn is offering is already ho-hum kind of stuff.

9) Competition - I want MS to have to compete, so they are forced to innovate, service their customers better, fix their security problems, and lower their prices. Therefore I want to give alternatives a chance - and there are very good, viable alternatives.

10) Monopoly business practices - MS is infamous for the way it bullies it's partners, OEMS, ISVs, customers, and competiton. MS is also an amazing FUD machine. MS is a convicted monopolist and anti-trust violator. MS has also been sued many times for stealing IP. I won't go into details here, because it would make my post three pages long (or longer). But if MS's monopoly is broken, they will have to compete, and they won't be able to get away with their underhanded, bullying tactics anymore.

I don't want to be an anti-MS zealot or troll. But it's a good thing to inform people about the bad things regarding Longhorn and MS.

For those of you who are jazzed about getting Longhorn 3 years from now, knock yourselves out. I sincerely hope you enjoy it and it works out for you. But I will already be gleefully enjoying the superior alternatives.

 

Funny stuff.

For those of us who write code for a living and want to keep doing it for the forseeable future, the Microsoft Longhorn site contains a plethora of info about what to expect when it ships next year.

 

I write code as well (for Windows and other platforms), and your comment leads me to my item number 11:

11) Longhorn presents a moving target for developers. For one, all of that software written for Win32 will have to be rewritten. Two, VB developers have to completely rewrite their code to conform to VB.Net. Three, .Net will change it's framework to conform to Avalon, so a large portion of .Net code will have to be re-written. That's lots of work.

 

Moving targets occur because as operating systems evolve, older programs become obsolete and have to be scrapped or rewritten. It's called progress. I don't write Win16 code anymore, and I don't know anyone who seriously makes a living as a Windows programmer who does.

That's wrong. Win32 code will work in Longhorn, and Win32 apps will NOT have to be rewritten. I've written a layer between the .NET framework and DDE so that I can intercept calls between a VB 6.0 telephony application and a Powerbuilder 8.0 database application that used DDE to talk to each other. I put my C# code in between those by writing an unmanaged C++ DDE Server/Client that is hosted inside a managed C# Windows service. The web server also has a .NET remoting object that broadcasts to all clients and I convert those calls back to DDE messages via my C# Windows Service. Is it a complicated architecture? Yes, it is, but it works. I advised the client to scrap DDE, but that was not an option.

Also wrong. It is not at all true that all VB code has to be rewritten to run in Longhorn or in conjunction with the .NET Framework, as my example above shows. VB 6.0 and previous versions will run as unmanaged code, just like all other exisiting non .NET Windows applications do. To convert a VB application to a VB.NET app does require a rewrite, but if that cannot be done for business reasons, there is nothing preventing an unmanaged VB app from running in Longhorn. It is also quite easy to use ActiveX, COM, DCOM and COM+ in .NET applications. It's just a matter of knowing how to do it.

Also wrong. If an application is written for the .NET Framework version 1.0 or version 1.1, it will work perfectly, with no modification, in the .NET Framework 2.0.

As far as I'm concerned, having lots of work is a good thing. YMMV.

 

Backwards compatibility can be maintained. Original Java code from Java 1 can still run just fine in Java2. I'm not a Java developer by trade (I just play around with it at home), but this I do know.

That was a very good setup you did, and you obviously know your VS.Net development. But that involved some hoops to jump through, and for companies that have built their products on Win32, COM, VB6, VC++ etc. (my company, for instance), this type of solution is simply not practical. It's fine for dynamic business apps that don't have a long life cycle, but it doesn't work for large scale, commercial software, in practical financial terms.

We have close to two million lines of source code, that involves tons of API calls, registry entries, sockets, and various Windows services. So rather than opt for a migration to VB.Net or C#, we opted for C++ (this will improve the speed anyway). We still haven't decided on the GUI conversion. We might go with VB.Net, with ATL/MFC (using COM wrappers). Or we might go with a third party, cross platform GUI library like QT.

Also, our software is a multi threaded service, that can support hundreds of wireless/wired thin clients. So not only can we not implement the solution you used (due to programmer man/hours limitations), but we can't take the risk of a performance hit caused by running in a virtual machine (the CLR). There isn't much of a performance hit for small apps, but for large, heavily scaled apps, the CLR performance hit could be significant. This can be compensated for by using faster CPUs and more memory, but that reduces the value proposition of our software.

Finally, since C#, VB.Net, and managed C++ compiles to intermediate byte code, we would have to pay for an obfuscator, to protect our source code, which we don't want to do if we don't have to.

I don't know where you are coming from here. In case you haven't noticed, VB6 and VB.Net are completely differant languages. VB.Net has more in common with the pure OOP languages C# and Java, where everything is an object, there is Java/C++ style exception handling, and you have to create references to class libraries. For instance something like widget.subwidget.blue.circle.button.click, as opposed to simply button.click - no, this is not a real example, but it is how it is with common objects in VB.Net compared to VB6. We tried to do a small scale conversion of a sub set of our VB libraries, with very bad results (at least bad according to our expecations). The conversion would not run at all without major tweaking and/or rewrites of large portions of the source.
So, for us, in practical terms, a total rewrite would be required.

I can't contradict you with my personal experience, but every developer review I've read online, along with discussing this subject with customers who've been using .Net, have all indicated that the current .Net has some compatibility problems with the first .Net, and that .Net for Longhorn will have greatly alterred class libraries.

And, based on MS' history with service packs, new MS versions often leads to broken apps. You made a great point about software having to evolve, and having to abandon old frameworks in the name of progress. But there is a balance when implementing new technologies between advancement and backwards compatibility.

Lots of work is a good thing for developer job security, that's for sure. But I want to be able to deliver projects on time, with little or no bugs. If I have to do a lot of conversion tweaks and/or rewrites, then I'm at a disadvantage.

Yes, as I've already mentioned, we are in a gradual process of converting all of our source to C++. We might have done this anyway for speed/scalability/OOP reasons, but we are forced to do a major conversion over time, because of what MS decided to do, rather than on our own terms.

We wished that MS went with an enhanced, extended, fully backwards compatible VB7 instead of totally redesigning the language. The CLR, supporting multiple languages is a cool thing and I applaud MS for making such a thing. But they didn't do what the market really wanted. In a poll of VB developers, approximately 30% said they would go to VB.Net, 30% said they would go with C#, and 30% said they would go with Java. That's not exactly eager adoption, and I'm sure MS was not pleased at the prospect of potentially losing 30% of it's VB mindshare. Also, do a search on Dice.com for VB, then a search for VB.Net. VB returns about 3500 matches nationwide, and VB.Net returns about 900 (the last time I did this). This indicates that companies are still maintaining VB6 code, and are only reluctantly upgrading to VB.Net.

Sorry people, Mike and I highjacked this thread with technical mumbo jumbo. I'm, for one, sorry if I bored you guys, if you happened to read these last two posts. Now, carry on with Longhorn talk!

 

I hope you charge a lot of money. I live by the maxim "Faster. Better. Cheaper. Pick any two." I write research software, and - if you only operate the software within the very specific domain it was designed to operate in - I can barely deliver on all three. Barely. If you try to operate the software outside of the predefined limits, I can make no promises about it's behavior. If you want to improve it's reliability across all situations, either give me more time, or hire on some help. On time, and with "limited" bugs (nothing is ever bug free) is usually impossible with the money management makes available.

Technical mumbo-jumbo is fine around here. There are plenty of technical people who appreciate it.

BTW, my home network is still primarily based on W2K. I hate XP Home, and have no real need to update to XP Pro. My TiVo is Linux - and will obviously remain so, and my Xbox is Windows-based, and will also remain so. I hope to migrate my network over the next five years or so entirely to Linux. I doubt I'll be able to do it - I'm certain there will be some software I use that doesn't have a viable alternative (defined as of equal functionality that "The Management" approves of) on Linux, necessitating at least one box that has some flavor of Windows - maybe Longhorn? - on it.

 

Well said. I've seen a number of techie alpha gurus on the web say the same thing picking whether you want it faster, better or cheaper - pick any two. Software development is a very complicated process, and unfortunately a lot of management and end users/customers don't comprehend what it takes to write good software.

And because of the complexity, combined with end users not fully understanding the complexity, I was alluding to Mike that with this in mind I'd rather not have to worry too much about converting an existing, working code base from VB6 or VC++ to .Net, unless there is an extremely compelling reason to do so.

Ah, fellow geeks.

Anyway, good luck on converting your home network to Linux. As for still using Windows apps for which there is not good Linux version - It's pretty easy to set up at least one machine as a dual boot. The more polished, mature Linux distros easily detect a Windows installation and put themselves into the MBR, so that you can easily choose which OS to boot into.

 

I'm a consultant, and I try to stay ahead of the curve. The way I look at it, the more I can learn about Microsoft's new technology the better. If a client hires me to teach them something that I've already learned, that's fine by me. I seriously doubt that I'll starve following Microsoft's vision for what business software should be.

I've been programming for Windows since Windows 3.0. Is Microsoft perfect? Far from it. But so far, so good. I'm on the .NET bandwagon for as long as it lasts. And if Longhorn is the next step for that, I'll willingly follow along.

One thing I've learned in this business is that betting against Microsoft is not usually a good idea.

 

You will probably acheive good job security following along with .Net. Believe it or not, I think that .Net is a good framework and is a fierce competitor to Java. MS excels in it's development tools, in ease of use and productivity (except when you have to big overhauls of existing code base in order to conform to their latest stuff, as I've already pointed out). So there is nothing wrong with being a .Net developer, or with getting jazzed about Longhorn.

There will always be work for competent MS developers. I'm one of those as well. But I also like to stay on top of the Java field, as well as Unix/Linux, because there's a heck of a lot of it out there (and those technologies interest me as much or more than MS technologies). And for my personal home usage, I'm wanting to use MS less and less, for all of the reasons on my original post.

And I used to be an MS only kind of guy. Now, I'm platform nuetral, with a bias towards the best possible technology, for the best possible value, which services it's users the best, which embraces open standards the most (avoiding vendor lock-in), and encourages a competitive technology landscape. If in pursuing that goal I have to do a bit of MS bashing, so be it. I mean no offense to anyone loyal to MS products.

 

BTW, Mike I love your new Avatar - Posh Boy with "Penalty Taking for Dummies" - LOL

 

Interesting.

I take it the Windows (or win32?) API has problems. Is it really that poorly designed or implemented that they have to majorly work over the API? As compared to, say, POSIX. I guess reuse and portability aren't priorities, but running old binaries in emulation is.

I mainly do DSP firmware development, so I don't deal with the above issues. There's no substitute for C or assembly in embedded systems. Well, actually, there's VHDL but that's a whole other barrel of monkeys.

Back on point: our debugger and tools suite is written utilizing Tcl/Tk. The vendor has ported from Sun Solaris to Windows 95, Windows 2000 and to Linux with apparently very little trouble. Apparently, the hardest part was rewriting their JTAG PC card drivers.

As for Longhorn- woohoo, new computers for everyone! Maybe we'll upgrade from Windows 2000 then.

At home, I run a Gentoo Linux distro dual-booting with Windows 2000. I also have a old 333 Mhz file server running Debian. At work, it's heterogenous: Sun servers, Linux and Windows boxes.

Maybe when I have time, I'll look up AMD 64 info- I plan on getting an AMD 64 at the end of the summer.

 

Actually, the Windows NT/2k/XP kernel is completely Posix compliant. The biggest problems the Win32 API has is age.

The .NET framework essentially runs on top of that kernel and virtualizes all calls in CLR (Common Language Runtime) complaint languages, like C#, VB.NET, J#, managed C++, the next version of Delphi, even Cobol.Net and Fortran.Net down to what is called Microsoft Intermediate Language (aka MSIL, or IL). This intermediate language is actualy what is executed by the .NET Framework and converted into OS calls. Because of the MSIL, you can write a class in C# and inherit from it in VB.NET, Managed C++, or any other language that supports the CLR. It really makes software reuse possible among a lot of different languages.

Here's a pretty good overview.

I used to be a C programmer way back in my DOS programming days. I worked on one project that where a PC running DOS controlled a medical device that contained a Motorola 68000 series (can't recall which one) chip on a serial port. We had to write some pretty low-level stuff, which was a combination of C and ASM. That was the first time I had to worry about Big Endian and Little Endian.

Again, you can still run Win32 executables in XP and you'll be able to run them in Longhorn too. You just won't have all the stuff the .NET Framework gets you. They Win32 stuff will run as "unmanaged" executable, which means the have almost free reign of the OS (within the constraints of the security that is set up).

If you're not running XP, you should check it out. It's much better than Win2k.

I'm planning to build a HTPC based on the new AMD 64 FX-53.

 

My degree is in Electrical/Computer Engineering, and boy to I envy you. My favorite classes in undergrad were the digital hardware design (mmm... Karnough maps! The Quine-McClusky Algorithm!) and microprocessor classes. God, how I loved programming in assembly! I almost secured a job with Lockheed doing hardware work at Goddard Space Center on satellites straight out of school, and boy that would've been awesome.

My least favorite classes? Dealing with those mouthbreathers over in the CS "software engineering" sequence who wouldn't know a 5-pin DIN from a HD-15 port, and were also complaining that we "weren't learning Java, since that's the future" (idiots - it's not the language, it's the techniques. Someday Java will be obsolete...). I'm certainly not saying that all CS students were morons, but it sure seemed like a lot of them were.

At this point, with nearly 4 years of software development work, I'm pretty much stuck in software, I think. A switch to hardware means a switch to "rookie" pay, and that's if I can even remember a lot of rusty hard-core EE stuff. *SIGH*

 

Actually, the NT kernel is more based on VMS. Back in the early nineties when MS decided it wanted to be more of a player in networking, it hired VAX's cheif engineer. No doubt, the architecture was very similar. So simlar, in fact, that VAX sued MS, and MS settled out of court (for a sum of $300 million, I think). VMS has similarities to Unix, but AFAIK it's not Posix compliant and neither is NT/2K/XP. Windows does have some BSD (a Unix variant) code in it, most notably the TCP/IP stack. But it's not a Unix kernel.

However, I would most welcome MS if it decided to use BSD as it's central kernal, and put Win32 and .Net and Avalon on top of it. Apple did the same thing with MAC OS X and it has worked out great for them. If MS did this, they would solve a lot of their security and stability problems (BSD is widely regarded as one of most stable OS's out there - Yahoo runs on it, for instace). And they would gain instant credo with the Unix/Linux crowd. End users wouldn't care, because their stuff would still operate the same. But they would be glad because their PC wouldn't crash as often. IMHO, MS should embrace open source, not fight it.

The Win32 API is indeed old. And it was sort of haphazzardly thrown together over the years, as MS was wisely concerned (for obvious business reasons) about quickness to market. This sentiment is thoroughly echoed by Charles Petzold (who is a cheif engineer at Microsoft and the author of many MS programming books). His book "Programming Windows - the definitive guide to the Win32 API" (which is an awesome book - every Windows programmer should get it) points this out in several sections. He said that the stuff is good enough to work, and needed to be delivered to market fast, which is why it is such a huge, jumbled mess. MFC and, even more so, VB hide the mess and make it easier for developers. .Net does as well.

Not to always contradict you, but that has not been my experience. In fact, Win2k is my favorite Windows version. I've been using it at work the majority of the time, with very good stability (and I beat the hell out of it). It doesn't have the bells and whistles that XP does, but in my experience it is a lot more stable. It does not have Unix/Linux stability, but very good nonetheless. I have XP at home, which my wife mostly uses (I usually prefer my Linux laptop ). She uses it for email, browsing, and playing video games. It crashes or freezes up all to often. And we've been hit by a few of the worms going around (we've got dial up at home and always doing the security patch downloads takes all night). Plus, XP has product activation, and Win2k does not. For me, this is an intrusion and an inconvenience. I want to be able to upgrade hardware as much as I want.

BTW, my favorite development language is C/C++. With these two, you can get as machine low level as you need to be, but you can also go with great high level abstraction wiht the C++ STL and a plethora of GUI libraries and IDEs. I love that power and flexibility. Also, C/C++ are not controlled by any corporation, so my code is (mostly) not at the mercy of the commercial interests of said companies.

 

You're right, I had forgotten at the time that when Cutler came to MS to work on NT, he based the kernel on VMS, not Unix/Posix.

I've been using XP as my main development OS for about the last two years. I admit that every now and then I have to reboot (like maybe a couple of times a week), but I've had to do it a lot less often than I did when I was using WinNT or Win2k. I'm also doing more web development in ASP.Net, building a suite of web apps, with some infrastructure built in a mix of managed C# and unmanaged C++. I like running Visual Studio .NET on XP much better than I did on 2k.

I still like C, but I like C++ better. And I think that C# is a really great language. I love the built in support for delegates and events, properties, getters and setters, summary tags, regions, and other features. I've coded in C, C++, VB, Pascal (Delphi), and other languages I'm forgetting. I think C# is one of the best languages I've seen in my career.

 

Mike, Foosinho and myself are all obviously programmers by trade. So all that stuff is second nature to us (and usually enjoyable banter ). Sorry about highjacking the thread from the non programmers who just want to get info about Longhorn.

Anyway, for non geeks, here is some basic info about Longhorn (and I'll try to remain neutral):

It will feature a 3D windowing system.

It will feature a new file system that promises to make it easier to find your files, and add extra security.

It will feature a MAC OS X style task bar, where when you drag your mouse over the program icons they enlarge and put up sub menus.

It will have .Net embedded into the OS. What that means to non programmers: Not much, other than it will make more programs easier to build.

It will require at least a gig of memory, and probrably at least a 2.4 MHz CPU or better to run satisfactorily, if early reviews are a true indication.

It will have DRM (digital rights management) embedded. This means that it will be more difficult or restrictive to make copies of your DVDs, CDs and software. It also means that MS and it's partners will be able to record most if not all of your computer usage (that is largely true already, with exisiting spyware).


To get a full perspective, there are many websites that have reveiws and specs and opinions on Longhorn, both good and bad.

 

Hello fellow programmers

100% agree, a thing of beauty, even replaced C/BAT as my language of choice when hacking together small utilities.

 

I have not used C# myself, but everyone who has loves it. Even a significant segment of the open source crowd (who usually detests MS) likes C#, as evidenced by the Mono project. MS deserves kudos for making really good development tools.

Java, which is very similar to C#, has a lot of strengths as well, not the least of which is cross platform capability and avoiding vendor lock-in (IBM, BEA, Oracle, Sun, JBoss as well as the open source Tomcat all offer major J2EE solutions).

C#, along with the CLI, is an ECMA standard, as submitted by Microsoft. However, MS hold patents, and ultimate licensing power, on the standard. Therefore Mono users, or any other implementors of .Net, along with end customers, are at the mercy of MS. Therefore, the true cross platform capability of Java, along with the true multi vendor support, is a major advantage Java has over C#.

Also, C++ has the advantage over both of them in that it is a non-proprietary, open standard, and is compiled to machine code (a major performance/resource advantage).

Plusses and minuses to all of them.

 

With two of Longhorn's major selling points/features, it looks like Microsoft is way behind the curve:

In comparison to WinFS, Longhorn's new file system to make finding files easier -
File search capabilities incorporated by Apples's Mac OS X:

http://story.news.yahoo.com/news?tmpl=story&cid=569&ncid=738&e=1&u=/nm/20040628/tc_nm/tech_apple_dc

In comparison to Longhorn's Avalon 3D window rendering system -
3D windowing system, from Sun Microsystems, with the Java based Project Looking glass:

http://www.eweek.com/article2/0,1759,1617825,00.asp


This stuff is already out there. Longhorn is slated for late 2006 at the earliest.