|
|
Just curious. I'm guessing it's like a halfway version with new features, but not enough to get a new Windows version. Is that about it?
"For fifty bucks I'd put my face in their soup and blow." - George Costanza
CP article: SmartPager - a Flickr-style pager control with go-to-page popup layer.
|
|
|
|
|
What's he been up to?
|
|
|
|
|
Man, if only Al Lowe were to make it. That not being the case greatly lowers my expectations.
|
|
|
|
|
Did you (the voter) mean the new AF-S DX prime? If so, yeah I may get it too
|
|
|
|
|
According to the E-Mail I got tonight, it's out, so hurry to your next shop...!
|
|
|
|
|
NETRICSA: Secret Duke's skeleton has been found!
Sam: Dude, you've been hanging here FOREVER!
I really enjoyed Sam's one liners about Duke.
Beside that I would like to see Windows 7 and Visual Studio 10 this year.
|
|
|
|
|
My second write in would be this (after the openvz comment..)
So both answers are about improving performance with virtulization.
John
|
|
|
|
|
And yes, Windows 7, Office 14 and the new MS C++ compiler (couldn't care less for the IDE, though)
|
|
|
|
|
OMG.. It will just use more resources.. I'm completly satisfied with VS2008
Win7 will be great.. less resource than Vista. Everything fine ;D
Don't try it, just do it!
|
|
|
|
|
The VS2010 you can test in the VPC seems to use about the same resources as VS2008. The nice thing about VS2010 is that it uses WPF, which is hardware/GPU accelerated. That should make VS2010 smoother and faster in the long run than VS2008.
|
|
|
|
|
Jon Rista wrote: The nice thing about VS2010 is that it uses WPF, which is hardware/GPU accelerated. That should make VS2010 smoother and faster in the long run than VS2008.
"Should" is my favorite English word.
|
|
|
|
|
As I'm moving my primary development away from the Microsoft ecosystem, OS X 10.6 "Snow Leopard" is definitely something that I'm waiting for.
Even though the Xcode development tools and Objective-C language are drastically different than Visual Studio and C#, I have to say that once you get used to them, it's nice to be able to connect C, C++, and Objective-C/C++ without any interop layers or marshaling. If you want a 64-bit version of your software, just check the box in Xcode or add -m64 to your command line and "it just works."
Paul
A .NET developer who now drinks the Ruby and Cocoa Koolaid.
|
|
|
|
|
Funny...with .NET, I don't check anything for 32bit or 64bit...it just works on either without any hassle at all. Welcome to the beauty of the CLR.
|
|
|
|
|
Now take your .NET code and interface with some managed C++ that has to work around differences between XP, Vista, 32-bit, and 64-bit, and it's no longer that easy. The software that I work on must take all of that into account. The simplest thing for us to do was mark all of the C# projects as "x86" which locks us to 32-bit executables. On 64-bit versions of Windows we run under the WoW layer and can compensate for it. Unfortunately this means we cannot take advantage of any of the 64-bit benefits.
I'm still looking forward to Snow Leopard. My next graphics-related application will be written in C++ for the core, then Objective-C++ for the GUI. All 64-bit. The imagery that I'll be dealing with is around 50GB per file, for a single image. I'll probably port the C++ core to Windows and write the UI using WPF. It'll still have to be 64-bit though. "Dumbing down" the program to work in 32-bits is possible, but painful.
Paul
A .NET developer who now drinks the Ruby and Cocoa Koolaid.
|
|
|
|
|
Jon Rista wrote: Funny...with .NET, I don't check anything for 32bit or 64bit...it just works on either without any hassle at all. Welcome to the beauty of the CLR.
Discover the beauty of portability with native code.
|
|
|
|
|
Snow Leopard is definitely my number 1 for this year. At work, I have to program in C/C#/ASP.NET, but as soon as I get home, it's all Mac. I haven't had a PC at home for over 5 years, and I've loved every minute of it.
I think that Snow Leopard will be a huge hit this year.
|
|
|
|
|
Paul A. Howes wrote: If you want a 64-bit version of your software, just check the box in Xcode or add -m64 to your command line and "it just works."
Unless you use some nasty assumptions about pointer sizes
Seriously, why do you think it is any different with Windows compilers?
|
|
|
|
|
Too true! I have seen (and fixed!) way too much code like that.
Flipping the switch in the VC++ compiler is easy enough, but you have to build two copies of everything; one for 32-bit and one for 64-bit Windows . OS X 10.5 is 64-bit at its core. There is no 32-bit version of the operating system to confuse things. The only reason to build things in 32-bit is for compatibility with older processors that don't support 64-bit.
So what version of Windows32XP64Vista are you supporting this week?
Paul
A .NET developer who now drinks the Ruby and Cocoa Koolaid.
|
|
|
|
|
Paul A. Howes wrote: The only reason to build things in 32-bit is for compatibility with older processors that don't support 64-bit.
And this is a bad thing somehow? You really should read some of Raymond Chen's articles about backward compatibility.
|
|
|
|
|
Did I say that compatibility was bad?
If you'd like me to read those articles, links would be helpful.
Paul
A .NET developer who now drinks the Ruby and Cocoa Koolaid.
|
|
|
|
|
He wrote so many articles about backward compatibility, here's the link [^] to search his blog.
|
|
|
|
|
Paul A. Howes wrote: but you have to build two copies of everything; one for 32-bit and one for 64-bit Windows . OS X 10.5 is 64-bit at its core. There is no 32-bit version of the operating system to confuse things.
I am confused now. If you don't build different versions, why do you have the compiler switch?
Paul A. Howes wrote: So what version of Windows32XP64Vista are you supporting this week?
I develop on 64-bit Server 08 and this is the only version I ever see.
|
|
|
|
|
Nemanja Trifunovic wrote: I am confused now. If you don't build different versions, why do you have the compiler switch?
As was stated in a post further up, the compiler switch exists for backward compatibility. Leopard (10.5) is the first version of the operating system to support 64-bit executables. If you're developing applications for Tiger (10.4) or earlier, then you have to compile for 32-bits. Since the default Xcode project settings assume this, you get 32-bit compiles by default.
This is not unlike Visual Studio assuming 32-bit XP as the default target for most application development.
Nemanja Trifunovic wrote: I develop on 64-bit Server 08 and this is the only version I ever see.
You're lucky. I develop desktop applications, not server applications. I cannot generally make that assumption. Walk into any Best Buy and half the computers will have 32-bit Vista installed and the other half, 64-bit. Most users do not know the difference, which means I either make both versions (32/64) of a product available, or I drop half of the potential customers. In some cases there are ways to work around the 32-bit limitations, but not always.
On Leopard I can assume 64-bit and know that only a few (<10%) users with older hardware won't be able to use it, just as you can assume that anyone using 64-bit Server 2008 can use your software.
Paul
A .NET developer who now drinks the Ruby and Cocoa Koolaid.
|
|
|
|
|
So again, how is it any different than Windows?
In Windows world you can choose to support i.e. only Vista and then you can worry only about 32-bit Vista executables which can work on 64-bit builds as well. If you want (or have to) support XP or Win2k you can do that as well, and I bet money it is much easier to support both Vista and Windows 98 than OS X and OS 9.
|
|
|
|