This is exactly what is needed. It would eliminate all the crap with packages and maintenence.
My recommendation is that the inner file have a fixed name like "main" or something like that so that the directory can be renamed without breaking the app. And instead of $THIS_PATH, the rule is to make argv[0] be the fully expanded path of the directory. This directory should also be automatically added to the front of $LD_LIBRARY_PATH and any similar paths for the running program.
If you want to put the directory on another disk, you can use a symbolic link to point at it.
NeXTStep and OSX do something like this, but both use an ".app" extension on the directory name, which I think is stupid.
Another useful thing to do, but possibly requiring massive work, is change the runtime libraries so that opening a directory and reading it returns the results of "tar" on that directory, and attempting to write such data produces a directory. This will make cp and all other programs handle directory trees transparently.
Re:Qt has better documentation
on
GTK-- vs. QT
·
· Score: 2
QT's documentation is done by their other product doxygen (look for it with Google) which is really quite excellent for producing complete and accurate documentation. It works by reading comments added to the source code, but, unlike other systems, those comments are quite readable and easy to type, and don't have to be in the header files.
We use it in-house and have been very happy with it.
PS: it is not linked to Qt at all and can be used to document any C++ code.
Fairly true, however there are two "alpha compositing" systems of interest.
One is rendering with alpha, into a window. The result is an image that shows the result of the rendering. You can set your "paint" to transparent, and fill a shape, and the resulting image shows a mix of your paint and what was there before. But you cannot then seperate it and recover the image that was there before you painted it. This is what NeXTSTep's PostScript rendering interface provided (though it was more complex than it should be).
The system being shown here is dynamic compositing of window images to the screen. You can recover the behind image (move the front window away and it reappears without the application having to redraw it). NeXTStep did have the main portion of this, which is a off-screen backing store (or double buffer, or pixmap, or whatever you want to call it). However they always composited it as though the window was opaque. They could have added this alpha fairly easily. One obvious effect was that NeXt could do opaque window drags on hardware that was MUCH too slow to do it under X or Windows.
As far as I can tell, alpha-based rendering and this alpha windowing are completely different and unrelated systems. You can have either one without the other.
Also another common mistake: NeXT did not use "Display PostScript". NeXT used a much superior system (though I liked NeWS better) where the creation of windows and management of them was done with PostScript as well.
Have you even tried a system where clicking on a window does not raise it? If you had you would know that the way MicroSoft does it is not user-friendly and is in fact an enormous hinderance to working with mulitple windows, just as the original poster said!
The "they can't raise the active app" argument is BULLSHIT and indicates that you are either a MicroSoft apologist or completely ignorant. The user can easily raise a window by clicking on the title bar or the resize border, or using alt+tab. In addition an application can raise itself in response to a click (for instance if you click on the otherwise dead area where there is no button or text field).
Also dig up the release notes for X10 from 1982, dammit. Early versions of X raised the windows on clicks because it seemed to be sensible. They removed this, despite the back compatability problems, because they realized, TWENTY F**KING YEARS AGO, that this was BAD!! And you wonder why there is hostility toward MicroSoft and accusations that they are holding stuff back.
Like the original poster said, this raise-on-click behavior has made overlapping windows almost useless and has resulted in many strange workarounds such as those tiled windows and "MDI" and always-on-top windows, (and "layers" under Gnome and NeXtStep, just to indicate that ugly workarounds are not just coming out of MicroSoft).
The "desktop metaphor" is not dead, but it has been seriously maimed by this brain-dead behavior.
These are not the same. The Render extension is for alpha-based rendering *into* a window. This is vital for producing anti-aliased shapes, which is why it is really really important. It can also be used to make transparent objects, but imho programs that want to do this are also trying to draw far more complex illustrations than XRender can do and would do it in their own memory.
This system seems to be the server alpha-compositing images of the windows onto the screen and keeping the actual window off-screen. This is the huge deal with OSX's interface, but it also existed in NeXT. This requires a lot of memory and processor time. It also gives you double-buffering, which is far more important to making a nice-looking gui, and (depending on the memory usage) the ability to make programs that only incrementally draw their windows, with no redraw events, which makes simple non-toolkit programs way easier to write.
It looks like the Win32 thing is a fixed level of transparency for the whole window, which is pretty primitive compared to OSX. Then again this may be the result of adding transparency to programs that don't understand it, though I'm suprised to see the window borders do not seem to understand it either (making the resize edge opaque would make this look a lot better, or copying the OSX transparent-when-inactive effect would be nice).
As far as I see rendering anti-aliased into the window is a totally different system. This is what XRender does. I don't know of any attempts to make X do this window compositing, there are some nasty back-compatability issues (such as no "flush" in the Xlib data stream to indicate when the back buffer should be copied to the screen, and the damn "visuals") which make it very hard or impossible. It is also unclear why both Win32 and OSX make such a big deal about this when antialiased drawing (which they also both have) is not advertised at all.
Some portions of the patent don't seem to mention color.
I have a paper but unfortunately it is from 1999 which presents this idea. "Anti-Matting and Compositing Digital Images, The Two Vector ART Imaging Model" by Micael O' Connor, Mario Nemirovsky, Randy Carr, from Zeva Digital Imaging, 11127 Palos Verdes Drive, Cupertino, CA.
This promises to allow encoding of the color of a piece of glass as well as the color of things painted on it by using 6 numbers (they call it two vectors). Normal alpha only allows "gray" glass with things painted on it.
The idea is imho obvious but the paper explores the non-obvious math needed to combine several of these images together so the compositing operation is transitive (ie (AxB)xC is the same as Ax(BxC)).
Unfortunately for the vast majority of uses the added color is not worth it, as all the effects are effectively simulated by painting the gray glass, and all 3D renderers are unable to produce this as output (though Renderman uses it internally). Also since it does not do refraction if we really want accurate compositing of clear objects we would need to render the image behind them anyway.
It may be relevant if you find out what kind of work was done to preserve gray shades in the masks, to make a softer edged matte (this would require a lot of work as the normal film used for mattes was very high gain and tended to turn everything into black and white). I would bet people were thinking about partial transparency in 1940 or so when Disney used their sodium screen process.
No, this claim is for a non-premultipled image, as opposed to a premultiplied image that was described earlier. They hide it a bit by describing the mask as "antialaised text" and trying to make the image uninteresting by calling it a "pattern" but this is just as obvious.
If A is the "alpha" and F is the foreground and B is the background, claim 1 is for math of the form:
Also, MicroSoft has also not engaged in "look and feel" lawsuits, despite a huge number of obvious copies of the appearance of their desktop.
There is good reason to believe most of MicroSoft's evil is due to the chance fact that they ended up in the monopoly position and not because the people are actually mean. In some ways we are a lot better off with Bill Gates doing this than if Steve Jobs or Scott McNealy were in that position of power.
I have a book printed in 1990 (Foley & van Dam Computer Graphics Principles and Practice, first edition), the references papers that talk about it.
Every program that combines images and works with true color uses this. It is impossible not to, the algorithim is totally obvious. True color images (ie where the numbers represent levels of red, green, blue, rather than be indexes into a color pallette) were in common use in advanced visualization and simulations in 1980, such as Evans & Sutherland flight simulators. I also saw photo touch-up software that could duplicate a portion of the image and put it somewhere else in 1979, and I believe it must have used this, as otherwise the edges of the cut piece would be visible.
PORT84, Porter, T., and T.Duff, "Compositing Digital Images," SIGGRAPH 84, 253-259.
This is the paper most-often cited, however I think it's main addition is the enumeration of compositing operators and the introduction of "premultiplied" images. Before that I believe non-premultiplied was used as that was the more obvious solution. Also PNG does not use premulitplication.
Even if Apple is going to be a pita about this, it does not affect PNG, as the file format itself does not do any compositing, it just stores a 4th "color" called the alpha. So I would not worry about it there. However Photoshop and Gimp and the in-house program I write for Digital Domain uses this, and about six thousand other pieces of commercial and free software.
Re:Bad screenshots for showing anti-aliasing
on
KDE 3.0 Screenshots
·
· Score: 2
Putting "Xft.core: true" into your.Xresources may help.
There should be some way to do the few.Xresources thing in the.xftconfig file, but I was never able to find any equivalent to this.
It sounds like.xftconfig format will be replaced real soon, since the current design is, according to the author of it, pretty near useless.
Damn right. Management is lying to you, pretending to obey your request that this be done on Unix.
Insist that there be at least one production machine running Unix right now so that you can test the cross-platform capability. Do all your development on that machine.
If you start out this way doing it cross platform is not too much difficulty. You have to write every bit for both platforms at once. Otherwise you will have a porting nightmare later (this can also happen if you write for Unix and try to port to NT). Try to encapsulate the differences to as small a part as possible. Put the differences in header files, try to use macros or anything there so no ifdefs are needed in any of your source files.
I recommend using Qt and the cygwin header files (like libstd) on NT. Use the Unix versions of all calls. Try to avoid needing the cygwin libraries, though, they are slow.
Things like threads are not too much difficultly if you limit yourself to the common abilities of both systems. You don't want the weird features of pthreads (or Win32 threads) anyways. You can put a lot of macros in the header files so there is no time wasted. Linux supports recursive locks even though pthreads does not, it is a good idea to use these to match how Win32 works. Look in the linux pthread.h header file.
Absolutely do not release anything unless you have a working executable with identical behavior on both platforms.
Actually I think Plan9 is a very good idea, and may be a much better aproach to making a microkernel. You could consider Plan 9 to be doing "message passing" but the set of messages is limited (to 17, I think). Ie there is a "read" and a "write" and a "walk" and several others. Each of these "messages" has a very fixed set of arguments, ie some have a big block of memory that needs to be sent to the message reciever, some the other way around, some return a new message pipe, etc. Since there is this limited set of types of messages they can be each hand-coded for maximum efficiency.
This limited set of "messages" also makes it trivial to insert filters between components. In Mach I believe any kind of filter will have to interpret the entire message description structure, right?
I think those Motif companies use wxWindows and other cross-platform toolkits to write for Windows, so Motif is the main competition.
MFC can only be counted as their competitor if Qt has some inroads in Windows-only software development. It is hard to tell, as Qt looks percisely like MFC, but I would guess that Windows code is 50% MFC (or Qt or other things that clone MFC so closely that you cannot tell). The rest is Visual Basic, in-house toolkits (all 3D apps seem to use these), java things, and maybe some OSS toolkits.
Anybody know if Qt is being used to develop Windows-only software? (it is ok if the reason is that the company hopes to port to Linux, but that is not their main goal right now).
You don't need Qt to "develop for KDE". Lots of other Xlib toolkits work just fine (I can plug the one I am working on, fltk which is LGPL and totally free for commercial use). Yes they lack some of the stuff that Qt has, so you need to decide if it is worth $2K to get those extra features...
Unix was considered a significant change from software design in the 60's. It made devices look like files, byte addressed the files, had hierarchial directories, had a very small run time library, multiple processes with exec and fork, and a lot of other stuff that was very ground breaking and really made it popular. In some cases people who first encountered Unix were absolutely floored by the incredible increase in simplicity and programmer power (I was).
Part of the absolutely rabid hatred of Windows is that there is pre-Unix stuff leaking back in. This is because Windows comes from DOS and that comes from CP/M, which is mostly influenced by RSX-11M, a 60's operating system. A typical example is the use of ^M^J for line breaks, this is based on the mechanical requirements of Teletype printers (where the motor was not strong enough to move the printhead and advance the paper at the same time, you can believe me that when communication was 110 baud there was no other reason to add one byte to every line!!). Other things are time stamps in local time (obviously stupid for networks) and case-independent filenames which make I18N impossible without security problems. In general this is all crap that should not be done by the underlying system (for instance case-independent filenames would be better done by a user-level matching algorithim that could correct spelling errors as well).
I would agree that Unix has not shown much great advances since about 1980 or so. But a lot of the problems are a refusal to use the "old" stuff. Unix started to turn into a mess when they started making file types that could not be named or created with open().
Yes, of course I should have written that. The problem is that on other machines writing it the first way does not cause any problems so I don't notice until the Alpha crashes. I then have to run the user's script in the debug version and find the division that crashed, and usually the fix is then simple. Sometimes I have #ifdef __alpha it because the fix slows things down, but usually the fix is quite logical.
The real examples are more complicated. Typically they are something like:
I think you are correct that Linux is as much of a barrier to market entry as MicroSoft.
I don't think it is because of the GPL. Obviously somebody can write an os without using the GPL code in Linux. MicroSoft did, and all the other big computer compainies have an old Unix lying around they can fix up. Even things like Atheos seem to be written from scratch.
The lock-in is due to hardware support. Basically if you want any hardware acceleration, or even the ability to run much hardware at all, you either have to use MicroSoft or Linux. Even BSD is in trouble. On Linux itself this hardware support has kept all attempts to replace X on the sidelines.
The lock-in is also due to programmer's knowledge. Making a new system that is "innovate" by definition means it must be different than Linux or Windows, and that means there are no expert programmers for it. It also means it is hard to port code to it.
In a lot of cases Linux is causing exactly the same trouble as MicroSoft.
The strange characters are introduced by MicroSoft Word when "smart quotes" is turned on.
They are in fact codes in the range 0x80-0x9F, which the ISO standard reserves for "control codes", and MicroSoft grabbed for some symbols they (and a lot of users) wanted such as ellipsis and the Euro character, and matching open/close quotes, which are the primary source of the problem.
Personally I think there is some stupidity all around. The reason this block of very valuable 8-bit codes was "reserved" when iso8859-n was desgined was becuase the standards organization was concerned that communications would strip off the high bit and they would turn into newline and other control characters. But really, why propose a standard that *requires* a working 8-bit connection, and then worry about what happens when the connection does not work?
And MicroSoft demonstrates incredible stupidity of their own. Their "smart" algorithim basically turns all apostrophes into close single quotes, unless their is a space before them, in which case it turns them into an open single quote. This removes the whole reason for making close single quote and apostrophe different characters! It even broke their own spelling corrector code (they fixed it, eventually)...
Hey MicroSoft, in case you really are stupid, here is my suggestion. How about you turn an apostrophe into a close quote only if there is a mismatched open quote before it! Apparently I am smarter than all the engineers at MicroSoft.
In a serious note, we should all admit that MicroSoft has "standardized" the meanings of these characters, and they should be added in exactly those places to ISO-8859-n and Unicode. Sorry, but there is no reason to leave that block empty, and this standard is literally millions of times more prevailent than any other. It is not even a bad collection of punctuation marks, as MicroSoft actually talked to people writing real documents, rather than a bunch of academics arguing about what Chinese letters are equal.
Though I like Alphas a lot, one problem with them is the *don't* implement IEEE floating point natively. There are enough differences that porting math to them is a pain.
One obvious problem is that divide by zero causes a seg fault. Lots of code I have does things like:
{double A = B/C; if (C!=0) do_something(A);}
The fact that I divided by zero is irrelevant because the result is ignored later. Finding these and rewriting them is a major pain in the ass.
You can compile with -mieee to get pretty good emulation, but that turns off all the parallel pipelines and slows things by 15% or so.
I believe Wine is LGPL. This allows closed source programs to use it, but any fixes they make to Wine itself have to be distributed as source with their program (or, more likely, returned back to the Wine maintainers).
I think the problem with running Wine on anything other than x86 is the need to interpret x86 machine code. Even if you got it to work, it would be slow.
You are right that compiling source code on Solaris and other platforms under Wine could work. But even there I expect Windows source code to have a lot of x86 assumptions. There are also problems with the fact that a lot of stuff requires a working Windows DLL, which would have to be interpreted anyway.
The bug only destroys partitions that are mounted. Unless the Linux partition can be mounted (can OS/X do this yet?) it would be untouched.
If I understand the bug right, if you have Itunes installed on a disk named "foo bar" (with a space in it) *and* you have a disk named "foo" (ie it matches the part before the space) the "foo" disk is wiped with the Unix rm -rf command.
I think the suggestion is that '$1foo' should produce an error if $1 contains a space. But '$1 foo' (notice the space after $1) does not produce an error. Also no error is produced if any of this is inside quotes.
I would agree that it seems unlikely that somebody will want to append a word to the last item in a list, and that any occurence of this is an error. If somebody did want the real effect of $1foo they would have to put it in quotes and into a temporary variable, and then insert that temporary variable.
Since MicroSoft is not retaliating against companies for doing this now (possibly because they are not allowed to, possibly because it would only piss off people who hate MicroSoft anyway), I think your worries here are groundless.
The dual-boot system is a huge deal. For the average person this is the only practical way to get a Linux machine. Right now one of the primary functions of a home computer is "run Windows". Being able to manufacture and sell a device that does both this and *other* functions is a huge win. Besides "run Linux" (which is likely to be the most popular "other function" initially), there is "run the specialized game os that uses your graphics card really really good" or "run this as a neato MP3 player", or "run kool closed-source system from NotMicroSoft, Inc".
Slashdot Mirror
My recommendation is that the inner file have a fixed name like "main" or something like that so that the directory can be renamed without breaking the app. And instead of $THIS_PATH, the rule is to make argv[0] be the fully expanded path of the directory. This directory should also be automatically added to the front of $LD_LIBRARY_PATH and any similar paths for the running program.
If you want to put the directory on another disk, you can use a symbolic link to point at it.
NeXTStep and OSX do something like this, but both use an ".app" extension on the directory name, which I think is stupid.
Another useful thing to do, but possibly requiring massive work, is change the runtime libraries so that opening a directory and reading it returns the results of "tar" on that directory, and attempting to write such data produces a directory. This will make cp and all other programs handle directory trees transparently.
We use it in-house and have been very happy with it.
PS: it is not linked to Qt at all and can be used to document any C++ code.
One is rendering with alpha, into a window. The result is an image that shows the result of the rendering. You can set your "paint" to transparent, and fill a shape, and the resulting image shows a mix of your paint and what was there before. But you cannot then seperate it and recover the image that was there before you painted it. This is what NeXTSTep's PostScript rendering interface provided (though it was more complex than it should be).
The system being shown here is dynamic compositing of window images to the screen. You can recover the behind image (move the front window away and it reappears without the application having to redraw it). NeXTStep did have the main portion of this, which is a off-screen backing store (or double buffer, or pixmap, or whatever you want to call it). However they always composited it as though the window was opaque. They could have added this alpha fairly easily. One obvious effect was that NeXt could do opaque window drags on hardware that was MUCH too slow to do it under X or Windows.
As far as I can tell, alpha-based rendering and this alpha windowing are completely different and unrelated systems. You can have either one without the other.
Also another common mistake: NeXT did not use "Display PostScript". NeXT used a much superior system (though I liked NeWS better) where the creation of windows and management of them was done with PostScript as well.
The "they can't raise the active app" argument is BULLSHIT and indicates that you are either a MicroSoft apologist or completely ignorant. The user can easily raise a window by clicking on the title bar or the resize border, or using alt+tab. In addition an application can raise itself in response to a click (for instance if you click on the otherwise dead area where there is no button or text field).
Also dig up the release notes for X10 from 1982, dammit. Early versions of X raised the windows on clicks because it seemed to be sensible. They removed this, despite the back compatability problems, because they realized, TWENTY F**KING YEARS AGO, that this was BAD!! And you wonder why there is hostility toward MicroSoft and accusations that they are holding stuff back.
Like the original poster said, this raise-on-click behavior has made overlapping windows almost useless and has resulted in many strange workarounds such as those tiled windows and "MDI" and always-on-top windows, (and "layers" under Gnome and NeXtStep, just to indicate that ugly workarounds are not just coming out of MicroSoft).
The "desktop metaphor" is not dead, but it has been seriously maimed by this brain-dead behavior.
This system seems to be the server alpha-compositing images of the windows onto the screen and keeping the actual window off-screen. This is the huge deal with OSX's interface, but it also existed in NeXT. This requires a lot of memory and processor time. It also gives you double-buffering, which is far more important to making a nice-looking gui, and (depending on the memory usage) the ability to make programs that only incrementally draw their windows, with no redraw events, which makes simple non-toolkit programs way easier to write.
It looks like the Win32 thing is a fixed level of transparency for the whole window, which is pretty primitive compared to OSX. Then again this may be the result of adding transparency to programs that don't understand it, though I'm suprised to see the window borders do not seem to understand it either (making the resize edge opaque would make this look a lot better, or copying the OSX transparent-when-inactive effect would be nice).
As far as I see rendering anti-aliased into the window is a totally different system. This is what XRender does. I don't know of any attempts to make X do this window compositing, there are some nasty back-compatability issues (such as no "flush" in the Xlib data stream to indicate when the back buffer should be copied to the screen, and the damn "visuals") which make it very hard or impossible. It is also unclear why both Win32 and OSX make such a big deal about this when antialiased drawing (which they also both have) is not advertised at all.
I have a paper but unfortunately it is from 1999 which presents this idea. "Anti-Matting and Compositing Digital Images, The Two Vector ART Imaging Model" by Micael O' Connor, Mario Nemirovsky, Randy Carr, from Zeva Digital Imaging, 11127 Palos Verdes Drive, Cupertino, CA.
This promises to allow encoding of the color of a piece of glass as well as the color of things painted on it by using 6 numbers (they call it two vectors). Normal alpha only allows "gray" glass with things painted on it.
The idea is imho obvious but the paper explores the non-obvious math needed to combine several of these images together so the compositing operation is transitive (ie (AxB)xC is the same as Ax(BxC)).
Unfortunately for the vast majority of uses the added color is not worth it, as all the effects are effectively simulated by painting the gray glass, and all 3D renderers are unable to produce this as output (though Renderman uses it internally). Also since it does not do refraction if we really want accurate compositing of clear objects we would need to render the image behind them anyway.
It may be relevant if you find out what kind of work was done to preserve gray shades in the masks, to make a softer edged matte (this would require a lot of work as the normal film used for mattes was very high gain and tended to turn everything into black and white). I would bet people were thinking about partial transparency in 1940 or so when Disney used their sodium screen process.
If A is the "alpha" and F is the foreground and B is the background, claim 1 is for math of the form:
output = B*(1-A)+F
This claim is for math of the form:
output = B*(1-A) + F*A
There is good reason to believe most of MicroSoft's evil is due to the chance fact that they ended up in the monopoly position and not because the people are actually mean. In some ways we are a lot better off with Bill Gates doing this than if Steve Jobs or Scott McNealy were in that position of power.
Every program that combines images and works with true color uses this. It is impossible not to, the algorithim is totally obvious. True color images (ie where the numbers represent levels of red, green, blue, rather than be indexes into a color pallette) were in common use in advanced visualization and simulations in 1980, such as Evans & Sutherland flight simulators. I also saw photo touch-up software that could duplicate a portion of the image and put it somewhere else in 1979, and I believe it must have used this, as otherwise the edges of the cut piece would be visible.
PORT84, Porter, T., and T.Duff, "Compositing Digital Images," SIGGRAPH 84, 253-259.
This is the paper most-often cited, however I think it's main addition is the enumeration of compositing operators and the introduction of "premultiplied" images. Before that I believe non-premultiplied was used as that was the more obvious solution. Also PNG does not use premulitplication.
Even if Apple is going to be a pita about this, it does not affect PNG, as the file format itself does not do any compositing, it just stores a 4th "color" called the alpha. So I would not worry about it there. However Photoshop and Gimp and the in-house program I write for Digital Domain uses this, and about six thousand other pieces of commercial and free software.
There should be some way to do the few .Xresources thing in the .xftconfig file, but I was never able to find any equivalent to this.
It sounds like .xftconfig format will be replaced real soon, since the current design is, according to the author of it, pretty near useless.
Insist that there be at least one production machine running Unix right now so that you can test the cross-platform capability. Do all your development on that machine.
If you start out this way doing it cross platform is not too much difficulty. You have to write every bit for both platforms at once. Otherwise you will have a porting nightmare later (this can also happen if you write for Unix and try to port to NT). Try to encapsulate the differences to as small a part as possible. Put the differences in header files, try to use macros or anything there so no ifdefs are needed in any of your source files.
I recommend using Qt and the cygwin header files (like libstd) on NT. Use the Unix versions of all calls. Try to avoid needing the cygwin libraries, though, they are slow.
Things like threads are not too much difficultly if you limit yourself to the common abilities of both systems. You don't want the weird features of pthreads (or Win32 threads) anyways. You can put a lot of macros in the header files so there is no time wasted. Linux supports recursive locks even though pthreads does not, it is a good idea to use these to match how Win32 works. Look in the linux pthread.h header file.
Absolutely do not release anything unless you have a working executable with identical behavior on both platforms.
This limited set of "messages" also makes it trivial to insert filters between components. In Mach I believe any kind of filter will have to interpret the entire message description structure, right?
MFC can only be counted as their competitor if Qt has some inroads in Windows-only software development. It is hard to tell, as Qt looks percisely like MFC, but I would guess that Windows code is 50% MFC (or Qt or other things that clone MFC so closely that you cannot tell). The rest is Visual Basic, in-house toolkits (all 3D apps seem to use these), java things, and maybe some OSS toolkits.
Anybody know if Qt is being used to develop Windows-only software? (it is ok if the reason is that the company hopes to port to Linux, but that is not their main goal right now).
You don't need Qt to "develop for KDE". Lots of other Xlib toolkits work just fine (I can plug the one I am working on, fltk which is LGPL and totally free for commercial use). Yes they lack some of the stuff that Qt has, so you need to decide if it is worth $2K to get those extra features...
Part of the absolutely rabid hatred of Windows is that there is pre-Unix stuff leaking back in. This is because Windows comes from DOS and that comes from CP/M, which is mostly influenced by RSX-11M, a 60's operating system. A typical example is the use of ^M^J for line breaks, this is based on the mechanical requirements of Teletype printers (where the motor was not strong enough to move the printhead and advance the paper at the same time, you can believe me that when communication was 110 baud there was no other reason to add one byte to every line!!). Other things are time stamps in local time (obviously stupid for networks) and case-independent filenames which make I18N impossible without security problems. In general this is all crap that should not be done by the underlying system (for instance case-independent filenames would be better done by a user-level matching algorithim that could correct spelling errors as well).
I would agree that Unix has not shown much great advances since about 1980 or so. But a lot of the problems are a refusal to use the "old" stuff. Unix started to turn into a mess when they started making file types that could not be named or created with open().
You are right that I could trap the SIGFPE, I have not tried that. If I just set it to SIG_IGN will that work?
The real examples are more complicated. Typically they are something like:
double A = B/C;
calculate_a_lot_of_other_values_here();
for (i=0; i<BIGNUM; i++) {
do_a_lot_of_stuff_not_using_A_or_C();
if (C!=0) do_something_2(A);
}
I don't think it is because of the GPL. Obviously somebody can write an os without using the GPL code in Linux. MicroSoft did, and all the other big computer compainies have an old Unix lying around they can fix up. Even things like Atheos seem to be written from scratch.
The lock-in is due to hardware support. Basically if you want any hardware acceleration, or even the ability to run much hardware at all, you either have to use MicroSoft or Linux. Even BSD is in trouble. On Linux itself this hardware support has kept all attempts to replace X on the sidelines.
The lock-in is also due to programmer's knowledge. Making a new system that is "innovate" by definition means it must be different than Linux or Windows, and that means there are no expert programmers for it. It also means it is hard to port code to it.
In a lot of cases Linux is causing exactly the same trouble as MicroSoft.
They are in fact codes in the range 0x80-0x9F, which the ISO standard reserves for "control codes", and MicroSoft grabbed for some symbols they (and a lot of users) wanted such as ellipsis and the Euro character, and matching open/close quotes, which are the primary source of the problem.
Personally I think there is some stupidity all around. The reason this block of very valuable 8-bit codes was "reserved" when iso8859-n was desgined was becuase the standards organization was concerned that communications would strip off the high bit and they would turn into newline and other control characters. But really, why propose a standard that *requires* a working 8-bit connection, and then worry about what happens when the connection does not work?
And MicroSoft demonstrates incredible stupidity of their own. Their "smart" algorithim basically turns all apostrophes into close single quotes, unless their is a space before them, in which case it turns them into an open single quote. This removes the whole reason for making close single quote and apostrophe different characters! It even broke their own spelling corrector code (they fixed it, eventually)...
Hey MicroSoft, in case you really are stupid, here is my suggestion. How about you turn an apostrophe into a close quote only if there is a mismatched open quote before it! Apparently I am smarter than all the engineers at MicroSoft.
In a serious note, we should all admit that MicroSoft has "standardized" the meanings of these characters, and they should be added in exactly those places to ISO-8859-n and Unicode. Sorry, but there is no reason to leave that block empty, and this standard is literally millions of times more prevailent than any other. It is not even a bad collection of punctuation marks, as MicroSoft actually talked to people writing real documents, rather than a bunch of academics arguing about what Chinese letters are equal.
One obvious problem is that divide by zero causes a seg fault. Lots of code I have does things like:
{double A = B/C; if (C!=0) do_something(A);}
The fact that I divided by zero is irrelevant because the result is ignored later. Finding these and rewriting them is a major pain in the ass.
You can compile with -mieee to get pretty good emulation, but that turns off all the parallel pipelines and slows things by 15% or so.
I think the problem with running Wine on anything other than x86 is the need to interpret x86 machine code. Even if you got it to work, it would be slow.
You are right that compiling source code on Solaris and other platforms under Wine could work. But even there I expect Windows source code to have a lot of x86 assumptions. There are also problems with the fact that a lot of stuff requires a working Windows DLL, which would have to be interpreted anyway.
If I understand the bug right, if you have Itunes installed on a disk named "foo bar" (with a space in it) *and* you have a disk named "foo" (ie it matches the part before the space) the "foo" disk is wiped with the Unix rm -rf command.
I would agree that it seems unlikely that somebody will want to append a word to the last item in a list, and that any occurence of this is an error. If somebody did want the real effect of $1foo they would have to put it in quotes and into a temporary variable, and then insert that temporary variable.
The dual-boot system is a huge deal. For the average person this is the only practical way to get a Linux machine. Right now one of the primary functions of a home computer is "run Windows". Being able to manufacture and sell a device that does both this and *other* functions is a huge win. Besides "run Linux" (which is likely to be the most popular "other function" initially), there is "run the specialized game os that uses your graphics card really really good" or "run this as a neato MP3 player", or "run kool closed-source system from NotMicroSoft, Inc".