Dude, what do you *want*, of/course/ that they will ad it to death if they donate moeny/services/computers/software. That is what companies *do*. Does this make it any less of donation? Or help the needy more?
Dude, you do know that there is nothing that prevents a windows user from going to the registery and changing whatever values you've there, right?
Not to mention, a secure 30 days trial can be achieved without a registery quite easily. A simple way to do so would be to record the date of the app server, or to create some sort of unique identifier & sign the date.
No, they would go a *long* way, because the *tools* for building those applications would support them. And if I can make a snazzy new UI easily, I *would*. So you would see a lot of fun apps just for longhorn, maybe with some backports for WinXP/2K.
The *serious* applications would remain neutral, but all the developer's toys (which are the funnest {yes, I know it's not a word} toys around) would be for Longhorn.
>Once you get used to building projects where you can view data paths from end to end with no opaque blocks in the middle, and once you get used to being able to compile debug code into any and every library, you'll never want to go back.
Dude, why *would* I want to debug the systems' calls. I just want it to *work*, and 99,9% of the time, it works. It's a sick developer that tries to debug libraries that he didn't write. {unless there is some extreme (read: usually rare edge case) cases - in which case you managed to prove that you didn't do anything wrong in your code, in which case, you might have an edge. But usually, just sending a bug report and finding a work-around would do.
Dude, what prevents you from taking any one of the dozens of Zip implementations out there? There are several packages that are open source Zlib comes to mind, frex/
Yes, there is a lot of investment in old Win32 code. Yes, there isn't such a big incentive *right now* to write code for Avalon / XAML. Yes, MSDN Magazine has the *wrong* attidue (notice the ratio of artciles about yet-unavailable technologies to availiable technologies in it recently?) As a matter of fact, personally, I didn't bother with them because I've more pressing concerns at the moments.
But, the thing is: By all accounts - Longhorn *will* keep the reknown MS' backward compatability. A> There hbeen nothing on the contrary. B> MS has a *really* good track record.
The so-called breaking changes (he mentions.NET 1.0 vs 1.1 and Avalon/XAML vs Win32) are mute, considerring that they *don't break backward compatability*.
The change in VB.NET is indeed a breaking change. But, it's not the first time that VB update break existing code (as a matter of fact, I think that is normal for VB, although the changes are usually minimal)
VB.Net is a new language, VB6 has reached its end, you might want to compare it to the transition from C to C++, you've to break compatability (for the furious: byte *buffer = malloc(1024); isn't legal c++) And if you're going to break compatability, why not do it in a way that is still largely the same, but gives you *so much more* freedom & flexibility.
The other choice would've been to exclude VB from.Net, and *that* is not something that MS could afford doing.
So, in short, Joel is talking about moving away from old technology (Win32) that he descibe as hard to use and error-prone to a better, OO, managed way of doing things. While at the same time *retaining* backward compatability.
I don't get it. Sure, a lot fo code is now not the newest & brightest, but you can say the same about COBOL.
About MS losing the desktop to Web app, that is bull. Personally, I can't *stand* using webmail, the latency there is killing me. Any sort of web app is usually a mess to write & maintain correctly - especially cross-platform(for example, Firefox 0.9 can't show *Slashdot* properly - I get all sorts of hovering errors when tables over-write one another. Strangely, IE show it perfectly well. And I usually use Firefox, for the reasons Joel mentioned).
Yes, MS made a big mistake with not updating IE, but I can see their point. If they are going to sell Longhorn, it needs to be more than snappy UI & pretty pictures (especially for the business client). It has to have *killer app* - IE 7 & WMP 10 are probably on top of the list at MS. I'm certain that we will so much improved applications that require Longhorn (DirectX for Longhorn isn't that much of a long call - by the time that it would be out, 2000 would be an old system, and MS can justify not supporting it on Win2K. Games are the #1 killer app, after all.)
Living being have quite a lot of unused historical matter in their DNA. The information isn't lost, it's merely isn't used, so if there is a need, it can be evoked quite easily, instead of having to discover it again.
DX is compatible down to version 1.0, and MS has a very good track record in backward compatability. I wouldn't worry about DX games stopping to function as long as they were written correctly.
In many israelian sites, there are flash commercials that cover the contents, and are very hard to close. You surf peacefully, and suddenly the screen is filled with lottery ad and the computer shouts " 50 millions!!! " at you. There are other things, like a anti-virus ad that looks like the computer has been compromised, etc, which are just plain agressive.
> Let me start by saying that programming COM objects is the most retarted way of programming functionality. True, using VB or Delphi, it is easy, but using f.e. C++, it's not. Read Don Box' book Essential COM to see what I mean.
No, it's not. First off, COM is a great way to combine parts of programs together. And if you want to have COM in C++, yes, you've to do quite a bit yourself, because in C++ you *don't* have things done under-the-scenes for you.
COM itself is quite simple, IUknown and nothing much beside it. The interfaces are complex, because you do quite a lot with them, and with combinations of them. That is why you can have a lot of stuff automated for you by librarys, ATL is a good example, but certainly not the only one.
Oh, really? IceWind Dale, Dungeon Siege, Dungeon Keeper II, etc. Are games that I play *right now* as non-Admin user on XP. Don't give me bullshit, *very* few games require admin privileges, and direct access to hardware is almost never done in Windows, because you've things like DirectX to provide a layer for you, without comprimising the speed.
Slashdot Mirror
WTF?
Didn't your hear about localhost?
Just run the server, and point your code to your own computer.
I do it all the time for my projects.
svn checkout svn://localhost/MyProject
Dude, what do you *want*, of /course/ that they will ad it to death if they donate moeny/services/computers/software.
That is what companies *do*.
Does this make it any less of donation? Or help the needy more?
You get what you pay for, if you want cast iron reliability, go get a 10,000,000 $ PC.
Yes.
> reverted instead to the, much deprecated, entangled monolithic approach
You mean, like... Linux?
Dude, you do know that there is nothing that prevents a windows user from going to the registery and changing whatever values you've there, right?
Not to mention, a secure 30 days trial can be achieved without a registery quite easily.
A simple way to do so would be to record the date of the app server, or to create some sort of unique identifier & sign the date.
No, they would go a *long* way, because the *tools* for building those applications would support them.
And if I can make a snazzy new UI easily, I *would*.
So you would see a lot of fun apps just for longhorn, maybe with some backports for WinXP/2K.
The *serious* applications would remain neutral, but all the developer's toys (which are the funnest {yes, I know it's not a word} toys around) would be for Longhorn.
>Once you get used to building projects where you can view data paths from end to end with no opaque blocks in the middle, and once you get used to being able to compile debug code into any and every library, you'll never want to go back.
Dude, why *would* I want to debug the systems' calls.
I just want it to *work*, and 99,9% of the time, it works.
It's a sick developer that tries to debug libraries that he didn't write. {unless there is some extreme (read: usually rare edge case) cases - in which case you managed to prove that you didn't do anything wrong in your code, in which case, you might have an edge. But usually, just sending a bug report and finding a work-around would do.
> Think they would care that zlib is the back end for the WinXP zip library?
Shouldn't they? If so, why not?
Why should *you* care? The code is there, it's compatible with WinXp, the license is nice. USE it.
>(Note that WinXP had to be patched for the zlib exploit a year or so ago)
Just like any other user of Zlib?
Dude, what prevents you from taking any one of the dozens of Zip implementations out there?
There are several packages that are open source Zlib comes to mind, frex/
Yes, there is a lot of investment in old Win32 code.
.NET 1.0 vs 1.1 and Avalon/XAML vs Win32) are mute, considerring that they *don't break backward compatability*.
.Net, and *that* is not something that MS could afford doing.
Yes, there isn't such a big incentive *right now* to write code for Avalon / XAML.
Yes, MSDN Magazine has the *wrong* attidue (notice the ratio of artciles about yet-unavailable technologies to availiable technologies in it recently?)
As a matter of fact, personally, I didn't bother with them because I've more pressing concerns at the moments.
But, the thing is:
By all accounts - Longhorn *will* keep the reknown MS' backward compatability.
A> There hbeen nothing on the contrary.
B> MS has a *really* good track record.
The so-called breaking changes (he mentions
The change in VB.NET is indeed a breaking change.
But, it's not the first time that VB update break existing code (as a matter of fact, I think that is normal for VB, although the changes are usually minimal)
VB.Net is a new language, VB6 has reached its end, you might want to compare it to the transition from C to C++, you've to break compatability (for the furious: byte *buffer = malloc(1024); isn't legal c++)
And if you're going to break compatability, why not do it in a way that is still largely the same, but gives you *so much more* freedom & flexibility.
The other choice would've been to exclude VB from
So, in short, Joel is talking about moving away from old technology (Win32) that he descibe as hard to use and error-prone to a better, OO, managed way of doing things.
While at the same time *retaining* backward compatability.
I don't get it.
Sure, a lot fo code is now not the newest & brightest, but you can say the same about COBOL.
About MS losing the desktop to Web app, that is bull.
Personally, I can't *stand* using webmail, the latency there is killing me.
Any sort of web app is usually a mess to write & maintain correctly - especially cross-platform(for example, Firefox 0.9 can't show *Slashdot* properly - I get all sorts of hovering errors when tables over-write one another. Strangely, IE show it perfectly well. And I usually use Firefox, for the reasons Joel mentioned).
Yes, MS made a big mistake with not updating IE, but I can see their point.
If they are going to sell Longhorn, it needs to be more than snappy UI & pretty pictures (especially for the business client).
It has to have *killer app* - IE 7 & WMP 10 are probably on top of the list at MS.
I'm certain that we will so much improved applications that require Longhorn (DirectX for Longhorn isn't that much of a long call - by the time that it would be out, 2000 would be an old system, and MS can justify not supporting it on Win2K. Games are the #1 killer app, after all.)
Living being have quite a lot of unused historical matter in their DNA.
The information isn't lost, it's merely isn't used, so if there is a need, it can be evoked quite easily, instead of having to discover it again.
Think of it as #ifdef for the genome.
You need to install the .NET Framework only if you have software that requires it
DX is compatible down to version 1.0, and MS has a very good track record in backward compatability.
I wouldn't worry about DX games stopping to function as long as they were written correctly.
WinXP.
Don't know SDL.
Voodoo 5, 64MB
I've no idea why it would be so. No other game show this problem.
The eyes certainly need calibration.
Ask anyone who needs glasses about it.
In many israelian sites, there are flash commercials that cover the contents, and are very hard to close.
You surf peacefully, and suddenly the screen is filled with lottery ad and the computer shouts " 50 millions!!! " at you.
There are other things, like a anti-virus ad that looks like the computer has been compromised, etc, which are just plain agressive.
Horrible performance on WinXP, Athlon 1.2G, 640MB.
We're talking about 5-10 fps, at 800x600
I believe it would take me about a day to implement the main ideas of COM on Linux.
The only hard part is marshalling.
> Let me start by saying that programming COM objects is the most retarted way of programming functionality. True, using VB or Delphi, it is easy, but using f.e. C++, it's not. Read Don Box' book Essential COM to see what I mean.
No, it's not.
First off, COM is a great way to combine parts of programs together. And if you want to have COM in C++, yes, you've to do quite a bit yourself, because in C++ you *don't* have things done under-the-scenes for you.
COM itself is quite simple, IUknown and nothing much beside it. The interfaces are complex, because you do quite a lot with them, and with combinations of them.
That is why you can have a lot of stuff automated for you by librarys, ATL is a good example, but certainly not the only one.
Should be:
template <shape T>
class ShapeArray
{
};
template <bounding_box<shape> T>
class Bar
{
};
template
class ShapeArray
{
};
Oh, really?
IceWind Dale, Dungeon Siege, Dungeon Keeper II, etc.
Are games that I play *right now* as non-Admin user on XP.
Don't give me bullshit, *very* few games require admin privileges, and direct access to hardware is almost never done in Windows, because you've things like DirectX to provide a layer for you, without comprimising the speed.