|
Massive runtime download needed for CityDesk
Joel claimed that CityDesk would not require any additional software to run the demo copy of CityDesk.
I was sceptical of this claim - after all, I was reading it on a Mac at the time, and was intrigued to see how his "no additional requirements" claim would work for me. And I was right to be doubtful. But even after locating a computer with the appropriate architecture, it wasn't enough to simply download CityDesk - I had to nuke the copy of Linux installed on it, and download this stupdendously large runtime called "Windows" before I could get the CityDesk demo to run.
But seriously... Joel thinks nothing of building code with dynamic dependencies on external components supplied by the Windows platform, because that's the platform his system runs on. With .NET we are currently in this bizarre halfway house position. It's a platform that is available on Windows but not installed by default. It's kind of like writing Win32 solutions back in the Windows 3.1 days - you could do it, and you knew that in the long run it was the right thing to do, technically, but back then it meant you had to ship users this whacking great big "Win32s" download so that Win32 programs would run on the Windows 3.1 platform. It was often just less painful to stick with the older 16-bit API. (And that API still works even today.)
Of course after a few years, the Win32 platform was effectively ubiquitous on Windows systems. This is why Joel is able to build programs which binds dynamically to Win32 components rather than linking them in statically, yet still have people be able to just download and run them without downloading any additional components. It's not that the code doesn't depend on external components that aren't shipped with the download, it's just that anyone running a less-than-ancient version of Windows already has those components. Give it a few years, and the same will be true of .NET.
This really has absolutely nothing to do with static linking. The demo of CityDesk depends on no fewer than 8 external components. It is most certainly *not* a self-contained statically linked program. The only programs that really fall into that category are operating systems, and embedded systems.
Ian Griffiths
Thursday, January 29, 2004
Proof read... Always proof read... Obviously I meant to say that Joel said that *I* would not need any additional downloads to run the demo of CityDesk.
Ian Griffiths
Thursday, January 29, 2004
The first version of Word for Windows came with a runtime version of Windows.
John Topley (www.johntopley.com)
Thursday, January 29, 2004
Actually, it might have been Excel.
John Topley (www.johntopley.com)
Thursday, January 29, 2004
Well, as a person in charge of applications development where the organisation decided to use .Net (a courageous decision to go with Version 1.0 of a Microsoft product - one made before I got here), I have to agree with Joel. We have just migrated to version 1.1 of the .Net Framework, and upgraded our development tool to Visual Studio .Net 2003.
We have been beset with numerous version conflict problems, and the Crystal Reports component that comes with the .Net framework now refuses to run. Applications that were working under 1.0 break severely under 1.1.
After 18 months experience, I am prepared to say .Net is a royal pain in the butt. There are some good concepts to it, but the product itself is rather poor. To me, Microsoft are trying to compensate for the major underlying design flaws in the concept of Windows with this monolithic Framework. Not to mention how a product that has been developed in the last year or two continues to thumb its nose at current web standards (XHTML? What is that?).
If I had the power here, I would throw out .Net, and move to some other development environment. Anything other than .Net.
Ken Ray
Thursday, January 29, 2004
Yeah, I was thinking along similar lines: I wonder why Joel is so fussy about .NET when for some reason he doesn't expect GDI32.DLL to be statically linked into his binary? :-)
But that argument would mostly be splitting hairs for the sake of argument. Joel is right -- the .NET runtime is a royal pain right now for apps. We mostly get away with it for Vault since most of our users already have it. But for normal people, that's a lot less likely to be true.
Eric Sink
Thursday, January 29, 2004
This is the chief reason why we chose to drop an MS-access database tracking system. It was written in access 97, and when the company migrated to win2k, access 2k came with it. Abruptly no one could get into the database.
Not a problem, just install access 97, right? Wrong. Configuration proved to be too difficult. We ended up spending time and effort in maintaining 2 front-ends to the same dB, with frequent outbreaks of data integrity issues caused by the dual version setup.
I think that Ian's point is correct. The .NET system has to be in place and consistent for a while before it'll truly take off and be relied upon. Also, new releases that cause differences in the API should be infrequent. It was that sort of thing that caused us to re-think our database strategy, and it's that sort of thing that could cause people to turn away from .NET.
van pelt
Thursday, January 29, 2004
Speaking of gdi32.dll, you can inadvertantly add a reliance on gdiplus.dll to your application and not even realize it until someone (hopefully not an end user) discovers the problem when running the program.
For example, the ATL class CImage, which can be used for loading & saving various image formats, implicitly links in gdiplus.lib via a '#pragma comment(lib, "gdiplus.lib")' in the header file (atlimage.h).
Although gdiplus.dll can be used with Windows 98 & above and NT 4.0 & above, it only ships with Windows XP, the .NET frameowrk, or if a copy of the dll is included in your installation (the redistributable dll being available from the msdn download site).
Semi-Anonymous Coward
Thursday, January 29, 2004
Van pelt - so why didn't you simply convert the database to Access 2000? And data integrity issues? You must have had a very strange (and dare I say, incorrect) setup.
Martha
Thursday, January 29, 2004
Eric,
I just read your article on MSDN, which I enjoyed. One thing that struck me though was the discussion of Java -- how you went hog wild for it when it first came out. Do you think you are doing the same thing with .NET?
One of the claims to fame about Vault is that it is written in .NET. Maybe in your market that matters, but in most markets it doesn't. People just want an apps that are easy to use and install.
Thursday, January 29, 2004
One BIG difference between Windows as a platform and .net as a platform:
Windows doesn't change everytime there is an improvement'/bug fix in the *programming langauge.*
Improvements/fixes to VB 6 are compartmentalized (largely) to just 1 or 2 MB of runtimes.
Also, the old VB runtime was very stable after just a couple of years. (I think vb 6 finally made it to SP4 or SP5 after what? 7 years).
So... if you're developing on .net and staying current, you're already to your second or third version of the .net distributable.
.Net covers Sooo much more that it's likely to change a lot. Even if the change is unrelated to what you're working on.
The real Entrepreneur
Thursday, January 29, 2004
"Windows doesn't change everytime there is an improvement'/bug fix in the *programming langauge.*"
Just about every single Windows service pack will break some program. Usually it's only obscure ones, but that have been some big ones in the past.
Windows NT had 6 service packs (more if you count the minor updates to existing service packs). Windows 2000 is at service pack 4, and likely to get another in the future. Windows XP is at service pack 1, and likely to see service pack 2 fairly shortly.
The .NET runtime has had one "service pack" in the couple of years it's been out.
It's really not doing too badly, especially considering that a service pack stand alone download usually clocks in over 100mb, where as the .NET runtime is closer to 20.
Sum Dum Gai
Thursday, January 29, 2004
.NET 1.0 has actually had two service packs. Unfortunately, SP1 was the "paranoia" service pack where Microsoft turned off Internet code because they suddenly didn't feel comfortable with it. They turned it back on in SP2 (which I'm sure must've fixed some other bugs, too :-p).
Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, January 29, 2004
Oh, and the .NET service packs show up as critical updates.
Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, January 29, 2004
Interesting how little is said about the Java runtime environments. MSFT is not alone in going down the massive download and version hell of runtimes. However, static linking is not the answer. How exactly would you go about creating the kind of malleable interface most portals now provide? Would you be able to drag in web parts at will? With flexibility comes complexity. Keep the pressure on MSFT to do a better job of diagnosing and repairing version incompatibilities.
RonSo
Friday, January 30, 2004
So what it boils down to is that some applications will be able to exploit .NET sooner than others.
Some organizations roll out .NET as part of their standard desktop setup. Some ISVs sell vertical solutions where they get to pre-install .NET. Some people are writing server-side solutions where only one machine or a small number of machines need the framework installed. (I've developed .NET solutions in all three of these scenarios in the last couple of years.) In these scenarios, deploying the .NET framework is either easy, or a complete non-issue.
But I would certainly agree that for desktop applications that need to run on machines you're not in control of, we're at a point where the benefits it offers have to be balanced against the fact that it's not ubiquitous. For some (indeed many) applications, it won't be the right way to go right now.
So I'm certainly not criticising Joel for not using .NET in CityDesk!
I'm just pointing out that this isn't a new problem, and it has nothing to do with static linking. The fact that, as someone else pointed out, an early version of Word or Excel shipped with a runtime copy of Windows indicates that this problem has always been with us: the "Do we target DOS or Windows?" question was no different in its day to the current "Do we target Win32 or .NET?" Static linking has never been a solution, and probably never will be.
Ian Griffiths
Sunday, February 1, 2004
 Recent Topics
Fog Creek Home
| 
