OS WARS MEGA THREAD (Now debating proprietary vs. open-source!)

[doggie015]

Moreover, since Macs can't use Orbiter anyway, it kind of defeats the purpose.

*clears throat* http://www.codeweavers.com/products/cxmac/
http://www.vmware.com/whatsnew/macsignupform.html
and finally if those do not work:
http://askbobrankin.com/windows_on_a_mac.html

Therefore: you CAN run orbiter on a mac!

 

[Hielor]

*clears throat* http://www.codeweavers.com/products/cxmac/
http://www.vmware.com/whatsnew/macsignupform.html
and finally if those do not work:
http://askbobrankin.com/windows_on_a_mac.html

Therefore: you CAN run orbiter on a mac!

Not particularly successfully, and that's still significantly more expensive (and less "easy") than just clean-installing Windows.

 

[doggie015]

Not particularly successfully, and that's still significantly more expensive (and less "easy") than just clean-installing Windows.

I'll admit it's not as cheap or "easy"; but it is a FULL install of XP that you can do as dual boot; 100% capible of doing ANYTHING that a windows PC can do!

 

[Hielor]

I'll admit it's not as cheap or "easy"; but it is a FULL install of XP that you can do as dual boot; 100% capible of doing ANYTHING that a windows PC can do!

At that point, all you've done is install a copy of Windows onto an overpriced machine. It'll have all the same "problems" that Windows already does, with the added inconvenience of needing to reboot the machine every time you want to do something in Windows...

 

[Sherrif of Nottingham]

Oops... did I start this? Sorry guys...

 

[computerex]

At that point, all you've done is install a copy of Windows onto an overpriced machine. It'll have all the same "problems" that Windows already does, with the added inconvenience of needing to reboot the machine every time you want to do something in Windows...

Ya, but you'll just restrict the use of Windows to Orbiter....For everything else there is the Mac .

 

[Linguofreak]

Why can't they do it one way or the other?

O-F staff note: posts moved here from [Rant] Why can't they do it one way or the other? thread.
-------------------

I recently ran into a problem caused by an addon .cfg file on a cross-platform game having been written on a Windows system. A filename was specified in the file with different capitalization than the capitalization of the filename on disk. Windows preserves capitalization when writing/copying filenames but ignores it when reading them. So the .cfg worked fine on the system it was written on, but failed on my Linux system.

Why did Microsoft have to adopt such a middle of the road approach to filename capitalization? If Windows ignores case when reading filenames it should ignore it when writing them, and if it preserves case when writing, it should be case sensitive when reading. :compbash:

 

[agentgonzo]

If you ignore capitalisation when writing names, then you end up with not being able to write any capitals (or lower case, depending on your choice) in the filename.

I don't know for certain, but I would imagine that the case insensitivity when reading is to have fewer errors for the users (remember this policy dates back to MS-DOS and probably IBM's DOS before that) and somepeople still get confused these days when they try to load porn.jpg and the file is actually porn.JPG and they get an error.

It's a decision in my books, but then again so is the strict capitalisation rules of unix. One works for some, the other works for the rest.

 

[Artlav]

It's a problem on the other side of the pond too - you can bash the closed source Windows as long as you like, but why isn't there a set of function to work with files in a case-insensitive way in the open-source Linux?
It's a hassle in OGLA to find a properly-capitalized file in Orbiter mess under Linux.

 

[orb]

It's a problem on the other side of the pond too - you can bash the closed source Windows as long as you like, but why isn't there a set of function to work with files in a case-insensitive way in the open-source Linux?

Isn't WINE case insensitive? I thought it was.:hmm:

-------------------------

That's because of compatibility reasons. Windows is DOS derived system, and needs to ignore case to be compatible in basic with previous versions of Windows. If they changed it now, most of current software operating on files would stop working without rewriting, or without WINE layer for Windows. Windows wouldn't be Windows anymore, but some new operating system if it's changed.

An example from XP: Not too long ago I looked at services part of Windows registry, and one entry had "System32", another "system32", and another one "SYSTEM32" in path name. Part of them were of course from external drivers and services, but most entries came there during Windows installation. If I found a switch enabling case sensitivity, a half of drivers and services wouldn't load at system boot.

 

[Face]

I recently ran into a problem caused by an addon .cfg file on a cross-platform game having been written on a Windows system. A filename was specified in the file with different capitalization than the capitalization of the filename on disk. Windows preserves capitalization when writing/copying filenames but ignores it when reading them. So the .cfg worked fine on the system it was written on, but failed on my Linux system.

Why did Microsoft have to adopt such a middle of the road approach to filename capitalization? If Windows ignores case when reading filenames it should ignore it when writing them, and if it preserves case when writing, it should be case sensitive when reading. :compbash:

This is only one aspect of the problem. A much more annoying one is collaboration across platforms.

If you have a team developing on Linux and Windows, the Linux users have to take great care in not producing case-folding-collisions with file naming. E.g. if a Linux user is naming a file "myTestFile.c" and another one "MYTESTFILE.c" and uses both files in e.g. a make build, every Windows user is out of the game...

IMHO opinion, case-folding or case-insensitive systems are mistakes. Granted, there is a history for it, but they are still mistakes. If your character-set allows different cases, your file-system should care for it, too. And since ASCII is around for quite some time now, I see case-folding as a big design-flaw.

Most arguments regarding better user interface are just cover-ups for the design-flaw, because you can always put this "feature" on top of the case-sensitive file-system. No one will ever do it, though, because no one would use such a "feature" in the end.

regards,
Face

 

[Kurt M. Weber]

It's a problem on the other side of the pond too - you can bash the closed source Windows as long as you like, but why isn't there a set of function to work with files in a case-insensitive way in the open-source Linux?

Because that wouldn't make any sense--having that API would not change the fact that, to the operating system, file.png and fiLe.pNg are different files, so if you tried to have an API to shield you from case sensitivity then if you actually had both of those files it wouldn't know which one you actually wanted.

It's not enough to have the API for it; it would be necessary to alter the underlying filesystem concepts as well--which, at this point, are too entrenched to make that a feasible solution anytime soon.

 

[Artlav]

Isn't WINE case insensitive? I thought it was.:hmm:

It's one of the solutions, but it's not a generic one.

Because that wouldn't make any sense--having that API would not change the fact that, to the operating system, file.png and fiLe.pNg are different files

I mean, an API to use when you don't know the capitalization of the file, only the name, like in windows-interaction tasks. If there is File.png and you ask for file.png, it gives you File.png. If there are file.png and fiLe.pNg, it gives an error.

 

[eveningsky339]

React OS

Have any of you guys heard of this?

http://www.reactos.org/en/index.html

ReactOS® is a free, modern operating system based on the design of Windows® XP/2003. Written completely from scratch, it aims to follow the Windows-NT® architecture designed by Microsoft from the hardware level right through to the application level. This is not a Linux based system, and shares none of the unix architecture.

This looks promising, especially to a guy like me, who holds on to XP only because of FSX/Orbiter and prefers Linux. The website states that it is in alpha stages, though.

On a side note, I just learned that Google is working on an OS as well, which also promises Windows compatibility...

 

[computerex]

I have tried the OS with virtualbox. Looks like a promising project. Pretty immature at this stage however. But they have made some staggering progress.

http://en.wikipedia.org/wiki/Google_Chrome_OS

 

[Unstung]

The OS certainly seems good to try once finished.
And, what's wrong with Orbiter in Vista/7? I use Vista myself, Orbiter (and Flight Simulator) seems to be running just as well as XP.

 

[eveningsky339]

I have tried the OS with virtualbox. Looks like a promising project. Pretty immature at this stage however. But they have made some staggering progress.

http://en.wikipedia.org/wiki/Google_Chrome_OS

Not sure why I didn't think of that... And here I am with three Linux distros being tested in virtalbox.

The OS certainly seems good to try once finished.
And, what's wrong with Orbiter in Vista/7? I use Vista myself, Orbiter (and Flight Simulator) seems to be running just as well as XP.

Personally, I had several annoying problems with Orbiter in Vista. It was about half as fast as it was on my XP. And I think the 64-bit architecture resulted in a few bugs. Haven't yet tried 7, though, but I've heard good things about it.

 

[Arrowstar]

It looks okay, but I'd be worried about copyright issues on some of those icons I see on desktops and taskbars. A few look awfully similar to their native-to-Windows MS counterpart.

 

[cjp]

I think, in the long term, ReactOS will be the end for windows, just like Linux and BSD have taken over most of the UNIX market.

In the mean time, remember that ReactOS is partially based on the Wine software. This is A Good Thing, because it eliminates a lot of double work, but it also means that application compatibility won't be much different from Wine in Linux.

So, if you already have Linux + Wine, ReactOS won't add much. It may be a bit faster, but OTOH the current version is quite unstable, and has many glitches. Worse than windows 95. The main advantage is probably its aim for native support of windows drivers. And its familiar user interface, but that can easily be emulated on top of Linux.

It looks okay, but I'd be worried about copyright issues on some of those icons I see on desktops and taskbars. A few look awfully similar to their native-to-Windows MS counterpart.

Shouldn't be a big problem, they can easily be replaced if necessary. But I don't think it will be necessary, because to me they look more similar to icons I've seen on the Linux desktop than to windows icons. And these Linux desktops have never been a problem either.

 

[Hielor]

I think, in the long term, ReactOS will be the end for windows, just like Linux and BSD have taken over most of the UNIX market.

Just like how Linux was going to be the end of Windows back in the 90s?

ReactOS has a long way to go to even catch up to where Windows is now, and in that time Windows will be continually moving.