|
The fact is, George, people are still complaining on how difficult computers are to use, even with Windows. How do you expect them to cope with UNIX?
Microsoft are trying to get rid of DLL hell. That's what COM was about, and that's what .NET is about. Together with the new installer service, this can reduce user irritation, and puts the onus on the developer to make a clean installation script.
As an example, I was recently installing a PERL-based app on a web hoster's server for a client. The PERL app needed several modules which were not installed. Although the technical support staff were very willing, they didn't have a clue how to install these modules. If tech. support have difficulty with a relatively simple task like this, how do you think Gran'ma Ethel is going to cope? She's not. In fact, she wouldn't even get close. You may argue that PERL is not compiled, but the fact is, even tech support get confused sometimes. While this remains true, Windows setup, though not perfect, is the only viable alternative for 99.9 percent of our clients.
Speaking of clients, I have yet to find one who didn't want Windows. This being the case, I will continue to develop for the platform of choice. Why develop for the 10% when you can develop for the 90%? It doesn't make financial sense!
Cheers,
Karim.
|
|
|
|
|
>How do you expect them to cope with UNIX?
Usually "people" are not working with computers but rather with applications. So in fact the individual applications decide how easy or how difficult the work is. Typically, installation if a fraction of the whole time the computer is used, so it doesn't matter too much. Sure everybody says that vi is hard to use, but at the same time MS Word is as much confusing to the beginner. It's a matter of proper training to get used to particular software - then it all goes smoothly.
>people are still complaining on how difficult computers are to use,
>even with Windows
Well, with windows people mostly complain about crashes 
>Microsoft are trying to get rid of DLL hell.
>That's what COM was about, and that's what .NET is about.
Nah, that's not it. That's more about the money and power 
It's just replacing one hell with another. Also, .NET (Runtime error - object doesn't support the property or method.) is somehow a weapon against Java, specially C#.
>If tech. support have difficulty with a relatively simple task like
>this, how do you think Gran'ma Ethel is going to cope?
Well, are you sure those people are qualified to be a tech support? I notice a skills downgrade among the IT staff related to Windows, but I was always explaining that it's just my biased mind. You should see two sysadmins trying to figure out why two similiarly configured servers didn't work identical. All those jumping from one "properties" screen to another and trying to see if any checkbox or radio button is set differently. "Registry hell"? Any solution for that? Also it was so much fun to see them rebooting 10 times to no effect
>Speaking of clients, I have yet to find one who didn't want Windows.
>This being the case, I will continue to develop for the platform of choice.
>Why develop for the 10% when you can develop for the 90%?
Well, the right tool for the right job. Windows for the people, Unix for the server. Truly, anybody who cares about their data and reliability will prefer Unix, and a really big guys are almost always using Unix-based solutions. For the security, speed and stability. Those 10% actually holds 90% of money in their hands
Also, I don't care about "financial sense" - I do it for fun and joy of it, they pay me but it's not the most important factor.
|
|
|
|
|
I voted for multiple desktops with equal market share. No, I am not a masochist. But if that were the case, I could almost guarantee that more people/companies would put effort into cross-platform tools. Already there are some, there are interpereted languages such as Java, and also cross-platform C++ libraries, like wxWindows and Qt. You are right in that it can still be cumbersome to develop an application that works similarly in multiple platforms. If Windows weren't so dominant, I bet there would be more focus on creating good cross-platform solutions.
That being said, you can argue that the WinAPI itself is inconsistent... many APIs function quite differently on 9X than they do on NT, 2000, and XP, although users expect programs to work the exact same on all Windows OS's.
Variety is the spice of life.
|
|
|
|
|
> A good example of this is writing an application that runs under XWindow.
> Do you want to support raw Xlib, Motif, GTK, or Qt? Which version will you
> support? How can you guarentee that the end-user will have that particular
> library installed?
I'm about to delve into a little Linux C++ coding for XWindows. Is it even possible to make a statically linked executable program for XWindows?
I'm completely new to Linux, so go slow. 
|
|
|
|
|
As long as you have a static version of the library, then yes, you can link your program against it.
Netscape has always done this with Navigator and Communicatior. They are basically Motif applications, as is evident by the "look 'n' feel" of the window. However, the product was released long before Motif went open source, and Netscape was not authorized to distribute the Motif libraries, so they statically linked the whole thing. That is why the executable is so huge, and takes so long to load.
In the Windows world, you link against a .lib file. If that .lib file happens to correspond to a .dll file, then the .dll will be loaded at run time. However, if the .lib file was a static library, then the linker grabs the whole thing.
On all Unix variants that I am aware of, libraries come in two flavors: .a (static) and .so (shared object). Instead of needed two separate .lib files and the .dll, there are simply two library files. One is static and one is dynamic. Link against the appropriate one, and you're all set. The problem, of course, is that not every library is available in both flavors. A lot of times you have to take what you can get.
Good luck!
--
Paul
"I drank... WHAT?"
|
|
|
|
|
they definately have one thing going for them: Consistent APIs
Yep
I once worked a place where we both used Linux and Windows at the desktop (for security testing stuff).
When we got a new version of Windows, we just installed the good old program, and it worked
When we got a new version of Linux, the Linux guy had to compile all the programs, change a lot of code, on those that didn't work, and test them, before we could use them. 
A lot of the Linux programs we used just didn't work with newer versions...
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Why should our applications be run directly on OS?
I think most applications can be run on higher platforms than OS that ensure the standardization, then we can choose any OS.
The platform seems to be Java Virtual Machine now.
Though the Java apps is much slower than Win apps.
What do u think, eh?;)
|
|
|
|
|
The largest problem with using a "higher" (meaning abstracted from the underlying OS) platform for your application means that this abstraction is usually based on the lowest common denominator of all the OS's that it supports.
There are many features in both Windows and Solaris that are not supported by Java, simply because the feature is so specific to that platform. If you plan to take advantage of it, then you end up having to write some of your code in another language, and then use JNI to glue the pieces together. (Unfortunately, JNI is hopelessly slow, which precludes its everyday use.) You end up with an application that is locked to a particular OS, even though you wrote it in this wonderful platform independant language!
For the moment, most of the application development I intend to do will be Windows-based, and use C or C++. I just don't see the advantages of writing code for other platforms that do not have as large of a user base.
Another thing that I have against Java is that Sun wanted everyone to adopt it as a language that would run on anything, because the JVM would be so widely ported. Right now, we have solid JVM implementations for Windows and Solaris, because that is what Sun itself is willing to support. There are implementations available for other OS's, such as Irix, Linux, and FreeBSD, but the JVMs available are usually not the lastest verson (1.1 and maybe 1.2), they do not support the newer features of the language itself, and they do not support some of the newer libraries like Java3D and the JMF. The result of this is that I would only be able to support Windows and Solaris. The number of Solaris users who would want my software is small, which sends me right back to Windows. Now, what is the point of having a 30MB JVM to (slowly) run a 20kB jar file, when I could have used the WTL and ended up with a 50kB executable that runs 50x faster? Thanks, but no thanks, Sun.
--
Paul
"I drank... WHAT?"
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
