Vista is supposed to be faster, more reliable, and more secure. The result is that you can't assume your older Windows apps - particularly the ones you wrote - will work. DevSource.com's John Mueller points out where the bodies are buried in Vista's graphics, security, hardware, and third party applications, and where to start digging.
Post a Comment
Member since:
2006-02-22
>Vista is supposed to be faster
Really fun 
I had always found Windows Xp to be faster than my Kde on the same hardware.
I tested Windows Vista, it's a pain! On my dell inspiron 8600 with Nvidia Gforce 5200, it was slow, really slow!
And on this laptop, i run Debian with Kde 3.5 cvs / compiz cvs with full debug enabled! And it's 5 times faster than Windows Vista!
So, i think Vista will be slower, really slower...
Member since:2005-10-31
Member since:2005-07-06
I tested Windows Vista, it's a pain! On my dell inspiron 8600 with Nvidia Gforce 5200, it was slow, really slow!
So, i think Vista will be slower, really slower...
I have installed the beta 2 and it's not slower than XP or KDE latest on any amd64 Linux.In fact the overall networking performance is according to my perception faster than XP and on par with linux.
Member since:
2005-07-08
apps that are written in a interpreted language(.net/java), well most of them. I remembered an article in java.net where in they run netbeans in vista without recompilation, aside from a few graphical glitches, everything seems to work, even the look and feel.
Edited 2006-06-20 00:27
Member since:
2006-01-04
They always feared competition, they fear someone able to write a better app for their system, i.e. Mozilla vs IE, OOo vs Office, VLC vs MediaPlayer...
They progressively found the fit solution against competitors:
- bundle programs (Win bundled with PCs)
- bundle programs and make it nearly impossible to eradicate (IE, OE and MPlayer on Win)
- use closed format specifications (Office...)
- etc
The problem is that any strategy they used posed severe drawbacks to the users (few offers of PC free of MS bundle-tax, impossibility to really secure the system eradicating bogus unused components, difficulty of third part support to closed formats) and that allowed competitors to sue them and often win.
Now I clearly see a new strategy: let's just make a new "security (? we will see...) model" that allow only to our application to run without annoying to the death the customer, and the customer will only use our products.
I'm joking, but I wonder if I'm not near to the real reason of that byzantine, machiavellic bunch of ...choiches behind that security model.
Member since:
2006-01-02
Why would they ship debug code to customers? It's not really useful for MSFT to be running anything other than the final code on Beta machines. If problems arise, even the retail code has enough instrumenting and crash dumping for MSFT to have some clues as to what is causing a crash. And ultimately, they'd want to test the retail code on user machines since that's what they're shipping in the end.
I think Vista just hasn't had the full performance treatment applied to it yet. I hope they can make some significant gains here, or Vista will be a rather slow experience.
Member since:2006-05-26
Ok, you asked, and I'll tell you why: a release build of something doesn't do nearly as much logging, as a general rule. Even if a release build (that is, non debug symbols) crashes, it only gives an instantaneous "I've crashed, and here's a few register values and the current call stack(s) at the time" to decipher what happened. However, with a more complete debug build with symbols and logging, if they aren't overly concerned with top performance (why should they be, with a beta?) they can also log some number of system calls and state information leading up to the problem, which will give them better information to track down whether the application was violating previous programming guidelines and relying on undocumented features (or improperly documented features, of which there are too many to count on one hand) or whether that application found a situation where the beta changed behavior with a weird set of circumstances that weren't previously hit in testing, since there's a huge amount of possible states to test.
And this is the sort of thing why Mapou's statement about COSA leading to bug-free programs regardless of complexity is pure BS: it isn't the state machine representation and the programming language of something that determines whether something is bug-free or not, but the humans involved in interpreting and implementing and then testing the requirements with real applications. An application of any size is only as bug-free as the application is fully defined and understood by the developer(s) and user(s) that agree on a single definition of what is correct operation. Until we completely get rid of human beings in the design and implementation of software, applications that can be defined as "bug-free" will be incredibly rare for anything of any complexity beyond a Windows Note Pad clone, if only because one or more humans must explicitly decipher and handle all possible input states and provide a defined possible output state: this is why debug code with logging enabled for a beta should exist, and will slow things down quite a bit, so that holes in understanding of what has been covered can be found and filled.
Member since:
2006-06-14
Member since:2006-01-04
Member since:2005-07-06
