For your point 2, I have my doubts: if my customers have problems A,B and C, we can assume most of their competitors will have problems B, C and D. Therefore, the day they pay me to solve these problems, they'll be giving away money to solve their's competitor's problems too.
So his company will pay for enhancing a software that will benefit to everybody (sounds great), including all their competitors that are also offering support for the same software (sounds less great)?
This doesn't work: if profits are from support, and if everybody can support software developped by anybody else, then nobody will be willing to develop anything anymore.
This is the same problem with custom development: "sure I'll develop this add-on for you, it will cost $500k but once done, it will also benefit to all your competitors". Ouch!
If an application makes a system call it never calls or never can call in that order because it's been hijacked then this thing will stop it.
The problem is that, for any non-trivial program, it is impossible for a static analyser to decide whether the software will call or not and in what order a specific trap. For instance, that static analyser is not able to tell you in advance at what time the exit syscall will be called.
So they are comparing the program behavior and match it with a stripped version of the source code or the object file. Great! But what are they protecting themselve against exactly? If some virus tampered with the content of a binary or a shared object, whouldn't be more effective to implement a (trivial) checksum-based integrity mechanism? And if a black hat managed to feed a shell code through a buffer overflow, how will this tool distinguish between a legitimate fwrite in the software logfile against an fwrite to some other part of the disk?
Also, their fwrite example already yields a highly complex graph. I would like to see what snprintf gives, not to speak about any real-life software (say, a Java Application Server). You can't automatically predict what path a program will follow by just looking at the code (otherwise you would solve the halting problem), so I guess a non-trival program would give something like "any system call will occur anytime".
There is a world between true platform neutrality and easy platform port. I don't beleive into the first one (my own experience of non-trivial *client* applications, even written in Java), but I seek the second one.
About the Swing WindowsLookAndFeel, it is only an emulation and any experienced Windows user will dismiss it quite quickly. Especially if this user selects a custom desktop theme. If this theme decides that all buttons should be round, the Swing PLAF will still display square ones... There are zillions of details a Windows user would expect (such as double-clicking a column title separator to get it autosized for instance) that Swing "forgot" to implement. The same for any other platform.
Today my application is written for Windows users. The day I have to port it on Mac, I will need to change some parts of the GUI. Just because the way a Mac application behaves is not the same as a Windows application should behave. Windows uses a "control panel" paradigm while Mac uses a more "drag&drop" approach. Even if I had a perfect transparent portable GUI library, I would have to update the application according to the user expectations. SWT allows me to customize my application according to these expectations for some platforms and at a reduced cost. Swing prevents me from doing so on ALL platforms.
Swing is not an option when you need to create an application my mother should use. It is, however, a perfect choice when you need a cross-platform corporate application "à la" SAP.
I don't get the point here: SWT is platform-independent and it is therefore easy to port from one platform to another. I'm not talking about developing the application in VC++!
Swing is ugly, period. Why? Because it does not follow user's preferences and standard look&feel. Most of the previous posts seem to assume that the API is important. It is not. What is important is whether the user will like using your application or not. And, sorry, but most of the users are on Windows, and there is a standard look&feel Swing does not follow. Therefore, the users won't use your Swing application. Ever wondered why Java had so much trouble breaking through on the client side?
If you remember that most of the applications don't have to be run on all platforms, but only on some specific ones (Windows, MacOS), and that most of these applications won't need to be run from a webserver (common! my mother won't install a webserver just to use Excell nor to start her tax computing tool!), you only have the choice between.Net and SWT. Why? Because both are able to display a transparent red scrollbar if the user decided that all scrollbars should display that way. I want my Windows users to start a Windows application, not a Java application. I want my MacOS users to start a Mac application, not a Java application. They don't care about Swing or SWT, they really don't! But they want their nice-looking transparent red scroolbars!
Swing is a nice toolkit when you code software for other coders, or when your target audience is running Linux. For the remaining...
Slashdot Mirror
For your point 2, I have my doubts: if my customers have problems A,B and C, we can assume most of their competitors will have problems B, C and D. Therefore, the day they pay me to solve these problems, they'll be giving away money to solve their's competitor's problems too.
So his company will pay for enhancing a software that will benefit to everybody (sounds great), including all their competitors that are also offering support for the same software (sounds less great)? This doesn't work: if profits are from support, and if everybody can support software developped by anybody else, then nobody will be willing to develop anything anymore. This is the same problem with custom development: "sure I'll develop this add-on for you, it will cost $500k but once done, it will also benefit to all your competitors". Ouch!
If an application makes a system call it never calls or never can call in that order because it's been hijacked then this thing will stop it.
The problem is that, for any non-trivial program, it is impossible for a static analyser to decide whether the software will call or not and in what order a specific trap. For instance, that static analyser is not able to tell you in advance at what time the exit syscall will be called.
So they are comparing the program behavior and match it with a stripped version of the source code or the object file. Great! But what are they protecting themselve against exactly? If some virus tampered with the content of a binary or a shared object, whouldn't be more effective to implement a (trivial) checksum-based integrity mechanism? And if a black hat managed to feed a shell code through a buffer overflow, how will this tool distinguish between a legitimate fwrite in the software logfile against an fwrite to some other part of the disk?
Also, their fwrite example already yields a highly complex graph. I would like to see what snprintf gives, not to speak about any real-life software (say, a Java Application Server). You can't automatically predict what path a program will follow by just looking at the code (otherwise you would solve the halting problem), so I guess a non-trival program would give something like "any system call will occur anytime".
I don't know: when I installed XP from w2k, I also switched back from the "lego" interface to the old 2k theme.
There is a world between true platform neutrality and easy platform port. I don't beleive into the first one (my own experience of non-trivial *client* applications, even written in Java), but I seek the second one.
About the Swing WindowsLookAndFeel, it is only an emulation and any experienced Windows user will dismiss it quite quickly. Especially if this user selects a custom desktop theme. If this theme decides that all buttons should be round, the Swing PLAF will still display square ones... There are zillions of details a Windows user would expect (such as double-clicking a column title separator to get it autosized for instance) that Swing "forgot" to implement. The same for any other platform.
Today my application is written for Windows users. The day I have to port it on Mac, I will need to change some parts of the GUI. Just because the way a Mac application behaves is not the same as a Windows application should behave. Windows uses a "control panel" paradigm while Mac uses a more "drag&drop" approach. Even if I had a perfect transparent portable GUI library, I would have to update the application according to the user expectations. SWT allows me to customize my application according to these expectations for some platforms and at a reduced cost. Swing prevents me from doing so on ALL platforms.
Swing is not an option when you need to create an application my mother should use. It is, however, a perfect choice when you need a cross-platform corporate application "à la" SAP.
I don't get the point here: SWT is platform-independent and it is therefore easy to port from one platform to another. I'm not talking about developing the application in VC++!
Swing is ugly, period. Why? Because it does not follow user's preferences and standard look&feel. Most of the previous posts seem to assume that the API is important. It is not. What is important is whether the user will like using your application or not. And, sorry, but most of the users are on Windows, and there is a standard look&feel Swing does not follow. Therefore, the users won't use your Swing application. Ever wondered why Java had so much trouble breaking through on the client side?
If you remember that most of the applications don't have to be run on all platforms, but only on some specific ones (Windows, MacOS), and that most of these applications won't need to be run from a webserver (common! my mother won't install a webserver just to use Excell nor to start her tax computing tool!), you only have the choice between .Net and SWT. Why? Because both are able to display a transparent red scrollbar if the user decided that all scrollbars should display that way. I want my Windows users to start a Windows application, not a Java application. I want my MacOS users to start a Mac application, not a Java application. They don't care about Swing or SWT, they really don't! But they want their nice-looking transparent red scroolbars!
Swing is a nice toolkit when you code software for other coders, or when your target audience is running Linux. For the remaining...