Author Topic: Maybe Vista doesn't suck? (Read 69951 times)

f0dder · « **Reply #25 on:** November 19, 2007, 07:04 AM »

Still, it's a shame that almost all new versions of major software are betas. Doesn't anyone test this crap before they release it anymore?!!
-zridling (November 18, 2007, 10:11 PM)

Sure thing, but then you make a tiny little last-minute change, just a little innocent code reorganization, and... *b00m*. Of course that never happened to me, and certainly not with the fSekrit 1.3 release. *cough*.

I think some of this could have been cured if Microsoft would have only sold Vista in 64-bit versions, which would have forced anyone who wanted it to [effectively] buy a new system to run it.
-zridling (November 19, 2007, 04:21 AM)

Hear ye, hear ye!

I think it was a stupid move of MS to do a 32-bit version of Vista. Almost as bad a move as releasing WinMe instead of focusing exclusively on Win2k/NT5 - makes adaption take longer, spending more time on drivers, testing, etc.

Of course there's so many other things wrong with Vista that this isn't my biggests complaint, but still...

Ralf Maximus · « **Reply #26 on:** November 19, 2007, 07:36 AM »

I think it was a stupid move of MS to do a 32-bit version of Vista. Almost as bad a move as releasing WinMe instead of focusing exclusively on Win2k/NT5 - makes adaption take longer, spending more time on drivers, testing, etc.

Yes! They might have been able to shave years off the release date had they not done this. On the other hand...

The strategy has always been to drive corporate customers to early adoption first, then worry about the rest of the world. Consumer money's nice, but what they really want is the millions of dollars in upgrade fees from Fortune 500 organizations.

Had they dropped 32-bit support many corporate IT departments would've taken a pass. It's just that simple. Ironic how low Vista's adoption number have been in corporate america, right? As a strategy, it all looked so good on paper! Classic example of battle-plans not surviving contact with the enemy.

What baffles me: what's in the Vista feature set targeted to business users? Surely not Aero... so pretending that Vista is bug-free and wicked fast on old hardware for a moment, what on earth would compel a business XP user to crave Vista? I think a few must-have features (WinFS?) dropped off the list as development progressed.

If they're smart, they'll drop 32-bit in Windows 7 and keep cranking out service packs for XP until the new Intel 1024-bit terrahertz processors make that impossible.

f0dder · « **Reply #27 on:** November 19, 2007, 07:44 AM »

I didn't say they should drop 32-bit support - just not make a 32bit version. In the same sense that 32bit versions of 9x and NT don't have 16-bit versions, but can still run 16-bit apps through WOW.

This would still mean having to maintain 32-bit wrappers-to-64bit-native-calls and a few other things, but that's a whole lot less than a full 32-bit version of the OS...

Darwin · « **Reply #28 on:** November 19, 2007, 07:59 AM »

@nontroppo - I'm jumping in making some assumptions here, but wanted to note that I *think* Carol was referring to things like CMOS batteries WRT Macs computers (as opposed to the batteries that power laptops) and the non-user replaceable batteries in iPods. Of course, in the portable music sphere Apple is far from being the only manufacturer doing this - AFAICT Samsung, Sandisk, Creative, etc. all design their players this way. I don't know if this is to reduce the likelihood of the end-user mucking up their player or if it's got more to do with the technology and keeping the size down (probably a combo of both thought...). Hope I haven't misinterpreted what you were drivng at, Carol

nontroppo · « **Reply #29 on:** November 19, 2007, 08:17 AM »

What I don't understand is why did MS even insist on going 32 vs. 64 bit route? *nix and OS X handle this much more cleanly, and arguments have been made about why LP64 (*nix, OS X etc) is better than LLP64 (Vista):

http://www.unix.org/...hatsnew/lp64_wp.html

With LP64, I download a single binary that supports all platforms without having to worry (and neither did the developer during building). When 64bit apps come out[1], i can run them alongside my existing 32bit apps. This seems like a win-win. Is it because the driver model cannot handle such a shared environment?

Ah, CMOS batteries, no idea, though there arecompanies selling replacements for most macs since the 90s so this is not a general issue.

----
[1] Geekbench has tests for both 32bit and 64bit - I tested my machine for both without having to install two OSs, rebooting etc. There is a 8-10% performance boost for the areas covered.

Ralf Maximus · « **Reply #30 on:** November 19, 2007, 08:20 AM »

With LP64, I download a single binary that supports all platforms without having to worry (and neither did the developer during building). When 64bit apps come out[1], i can run them alongside my existing 32bit apps. This seems like a win-win. Is it because the driver model cannot handle such a shared environment?
-nontroppo (November 19, 2007, 08:17 AM)

I bet that's it. Though if that's the case, I don't know why they couldn't offer a parallel 64-bit driver stack for vendors to target. Or even "thunk" old 32-bit drivers for obsolete hardware; it'd be slower, but I bet people would accept that for hardware that isn't supported any more.

Carol Haynes · « **Reply #31 on:** November 19, 2007, 09:12 AM »

@nontroppo - I'm jumping in making some assumptions here, but wanted to note that I *think* Carol was referring to things like CMOS batteries WRT Macs computers (as opposed to the batteries that power laptops) and the non-user replaceable batteries in iPods. Of course, in the portable music sphere Apple is far from being the only manufacturer doing this - AFAICT Samsung, Sandisk, Creative, etc. all design their players this way. I don't know if this is to reduce the likelihood of the end-user mucking up their player or if it's got more to do with the technology and keeping the size down (probably a combo of both thought...). Hope I haven't misinterpreted what you were drivng at, Carol
-Darwin (November 19, 2007, 07:59 AM)

Nope - that is pretty much it. Can't see the argument working for the original iPods though which were built like bricks and could easily have had a replacable battery compartment. As for Creative they have now followed suit which is why I have stuck to the Zen Micro/Photo which has batteries you can change (I even bought about 4 or 5 spare batteries before they disappeared from sale).

I don't believe that the battery situation is anything to do with style or form factor - it is one way to guarantee that users spend even more money with the manufacturer and that third party battery manufacturers can't cash in on the deal. Otherwise why do Apple charge so much for battery replacements? For many people it is now cheaper to chuck their iPod and buy a new one which (like printer manufacturers who sell their goods cheaper than the replacement ink cartridges) is, IMHO, criminally irresponsible and a disgusting waste of dwindling world resources.

CWuestefeld · « **Reply #32 on:** November 19, 2007, 09:30 AM »

I think you're being too critical of the manufacturers. There's a definite advantage to using custom-sized lithium-polymer batteries. Standard AAA batteries force the design into a certain shape and (iirc) the energy density lithium-polymer is higher, so the AAA NiMH batteries would need to be bigger. The custom Li-polymer batteries allow the manufacturers to build the devices smaller (and with a definitive style).

As long as consumers value small size and style, custom batteries will be what you get.

f0dder · « **Reply #33 on:** November 19, 2007, 09:31 AM »

Imho ILP64 is the better choice, since "int" ought to be the "native int size", for performance reasons (okay, using 32bit ints isn't that bad on x86-64 because of how that architecture was hacked together, but still...)

Kernel and drivers need to be recompiled for 64bit. It would be possible to construct a thunking layer, but you don't want that for performance reasons. And it would take quite some work, since 32bit drivers obviously can't use 64bit pointers.

And some usermode apps on a 64bit os do need to be 64bit, or at least be 64-bit aware - as soon as memory addresses or sizes are involved.

nontroppo: when you download a "single binary that supports all platforms", it's probably 32bit. And that's doable on windows as well, since x86-64 natively supports running 32bit code (at the expense of not running 16-bit code in long mode). lots of code, both on windows and lunix, don't port cleanly to 64bit mode, because of st00pid programmers (NO, you CANNOT always fit a void* in an int).

You use an "int" when you want native integer size, you use "size_t" when you want address-space-size, ptrdiff_t when dealing arithmethically with pointers, etc. If you specifically need 32- or 64-bit integers (for file formats etc.), you use sint32/uint32/sint64/uint64 typedefs, specifically. It's not as complicated as some people want you to think, but you have to do this from the ground up, not as an afterthought.

For usermode code, there's a 32<>64 thunking layer, it's the most sane way to handle things.

Here's a bunch of links:

http://www.gamedev.n...cles/article2419.asp
http://www.viva64.co...it_Applications.html
http://www.viva64.co...our_egg_is_laid.html
http://www.viva64.co..._Windows_64-bit.html

Ralf Maximus · « **Reply #34 on:** November 19, 2007, 09:38 AM »

Here's a threadjack...

At what point will CPU registers stop getting wider? 128 bits? 256 bits? Surely there's a point at which we won't need to go further...

I don't want to sound like Bill Gates who wondered aloud why anyone would need more than 640K, but seriously, how much directly addressable RAM makes sense? Petabytes? Exobytes?

I guess I'm just looking forward to the "1024 bits sucks, you need Vista-4096" wars.

f0dder · « **Reply #35 on:** November 19, 2007, 09:45 AM »

Generic-use registers don't need to be wider than 64bit, this is quite sufficient (as long as there's CPU instructions that make working with arbitrarily large numbers easy enough) - for SIMD, they might very well get wider (and iirc SSE-something-soon will move from 128bit to 256bit). But for address space and general registers? I daresay 64bit is enough.

Carol Haynes · « **Reply #36 on:** November 19, 2007, 09:54 AM »

I think you're being too critical of the manufacturers. There's a definite advantage to using custom-sized lithium-polymer batteries. Standard AAA batteries force the design into a certain shape and (iirc) the energy density lithium-polymer is higher, so the AAA NiMH batteries would need to be bigger. The custom Li-polymer batteries allow the manufacturers to build the devices smaller (and with a definitive style).

As long as consumers value small size and style, custom batteries will be what you get.
-CWuestefeld (November 19, 2007, 09:30 AM)

Some Li-Ion batteries are tiny with good power output (such as the ones used in the early Creative Zen Micro) and much better and smaller than some of those used in other players - like the iPod early models. If the battery specs were released other companies would produce cheap replacements (just look eg. at the cost of Canon's Li-Ion replacements compared to the UniRoss equivalents and many other makes).

Sorry I am really cynical about this - how can Apple justify $100+ costs to replace a battery that would only probably cost $20 if others were allowed to manufacture them? It is just profiteering and most other manufacturers have simply jumped on the bandwagon.

nontroppo · « **Reply #37 on:** November 19, 2007, 10:12 AM »

nontroppo: when you download a "single binary that supports all platforms", it's probably 32bit.

Universal binaries support up to four platform architectures, 32 and 64bit PowerPC and Intel builds in one executable.

http://en.wikipedia.org/wiki/Fat_binary
http://www.apple.com...echnology/64bit.html

More than that I don't really understand, except that I don't have to worry about choosing a 32bit or 64bitOS as an end user.

f0dder · « **Reply #38 on:** November 19, 2007, 06:36 PM »

Ahhh, you're on Mac OS

Mac universal binary is actually an "archive" format, which contains multiple executables - one for each of the supported platforms. Which means that they are, as the wikipedia links says, fat.

It also means that each executable inside the fat binary is built specifically for the platform it targets, and that of course means the source code needs to be portable. So there's no magic, really.

nontroppo · « **Reply #39 on:** November 21, 2007, 04:27 AM »

No magic, just a bit of convenience

In general, I simply like the fact that i don't have to choose a 32bit or 64bit OS, I just have an OS that runs 32bit code and will run 64bit apps as they come out. This i hope will lower the barrier to developers ensuring 64bit portability, because everyone will be able to run them without reinstalling their OS.

If you are fat-phobic, there are apps on OS X that will put your apps on a diet, liposucking the platforms not needed out

f0dder · « **Reply #40 on:** November 21, 2007, 06:59 AM »

No magic, just a bit of convenience In general, I simply like the fact that i don't have to choose a 32bit or 64bit OS, I just have an OS that runs 32bit code and will run 64bit apps as they come out.
-nontroppo (November 21, 2007, 04:27 AM)

Then you have chosen (or rather, it has been chosen for you): you're running a 64bit OS. A 32bit OS won't run 64bit apps - the 32bit binary from the fatexe will be chosen.

That said, I heard something about the 64bit version of OS X being somewhat peculiar.

This i hope will lower the barrier to developers ensuring 64bit portability, because everyone will be able to run them without reinstalling their OS.
-nontroppo (November 21, 2007, 04:27 AM)

Actually it doesn't help wrt. 64bit portability - sure fat binaries are very smart, but it's still the programmer's job to, in source code, make sure his code compiles cleanly for both 32- and 64-bit modes. I'm not sure if xcode automatically compiles for each platform, or if you have to specify which platforms your fatexe should build for, but I can assure you that 32/64bit portable code doesn't happen by magic, you do need to design properly.

nontroppo · « **Reply #41 on:** November 21, 2007, 09:35 AM »

Then you have chosen (or rather, it has been chosen for you): you're running a 64bit OS. A 32bit OS won't run 64bit apps - the 32bit binary from the fatexe will be chosen.

That said, I heard something about the 64bit version of OS X being somewhat peculiar.
-f0dder (November 21, 2007, 06:59 AM)

Yes, the details have been obfuscated from the user, he/she just runs an app and if the platform supports it it will be 64bit.

As for being peculiar, in Tiger the core OS was 64bit, but the frameworks were not, so only specialised code could run and a seperate process was needed for a UI. Now, everything except for the old carbon compatibility UI layer (from system 8 days) is 64bit. This means some apps that still use that will have to transition away from it to enable transparent 64bit OS support.

Actually it doesn't help wrt. 64bit portability - sure fat binaries are very smart, but it's still the programmer's job to, in source code, make sure his code compiles cleanly for both 32- and 64-bit modes. I'm not sure if xcode automatically compiles for each platform, or if you have to specify which platforms your fatexe should build for, but I can assure you that 32/64bit portable code doesn't happen by magic, you do need to design properly.
-f0dder (November 21, 2007, 06:59 AM)

Oh, I agree. My point was that the potential 64bit user base is now every Leopard Mac that has a 64bit PowerPC or Intel chip, as a percentage of the total userbase that is going to be significant[1] (what is the proportion of 32bit to 64bit vista installs?). That gives a Mac developer incentive to do the grunt work to make his code portable, because in theory anyone with a newer mac and Leopard will benefit.

----
[1] A number of mac developers have suggested their next versions will be Leopard only because of the benefits Developers gain coding for Leopard. Most of their users feedback has been positive AFAICT, they have a high rate of new OS adopters.

f0dder · « **Reply #42 on:** November 21, 2007, 11:21 AM »

Oh, I agree. My point was that the potential 64bit user base is now every Leopard Mac that has a 64bit PowerPC or Intel chip, as a percentage of the total userbase that is going to be significant[1] (what is the proportion of 32bit to 64bit vista installs?). That gives a Mac developer incentive to do the grunt work to make his code portable, because in theory anyone with a newer mac and Leopard will benefit.
-nontroppo (November 21, 2007, 09:35 AM)

I dunno about the ratio - and I'd like to repeat what I've said earlier, releasing a 32bit version of Vista was a mistake. Just like it was a mistake not to put more pressure on driver manufacturer when XP64 was released. Lots and lots of 32bit windows code runs just fine under 64bit, and the problematic stuff is either stuff that breaks on non-administrative accounts (ie., from developers with a "win9x mindset"), or because of crappy protection code.

justice · « **Reply #43 on:** November 21, 2007, 11:42 AM »

According to known news (wikipedia), windows 7 will be released as 32bit and 64 bit too, so we're not done yet

f0dder · « **Reply #44 on:** November 21, 2007, 12:25 PM »

According to known news (wikipedia), windows 7 will be released as 32bit and 64 bit too, so we're not done yet
-justice (November 21, 2007, 11:42 AM)

Morons.

Vista is already at the point where you probably don't want to run it on hardware that isn't 64bit capable... I doubt Windows 7 will be better, sure their design ideas sound nice, but they'll fsck it up just as badly as they did with Vista. sigh.

Lashiec · « **Reply #45 on:** November 21, 2007, 03:25 PM »

I find stupid that they decide to release Windows 7 for 32 bits CPUs as well BUT that may mean the requirements of the OS will be similar to Windows Vista. 64 bit CPUs were introduced in 2003, even 7 years later we're going to deal with 32 bits... I was planning the move to 64 bits, but at this rate, even the AmigaOS 5 will be a 64-bits native build!

. Well, maybe they'll plug an XBOX 360 introducing a really cool product.

This poses the question, why move to Vista with Windows 7 down the road? It will be another ME, even if Microsoft didn't intend to make it so, and not being THAT bad, if everyone chooses that road.

f0dder · « **Reply #46 on:** November 21, 2007, 04:35 PM »

The only reasons for moving to Vista would be DirectX10 (which could be done for XP, but of course MS won't), possibly hardware drivers (Hybrid HardDrives not being supported on XP... although that's not too big a loss with the current generation of H-HDDs as performance is bleh), and when applications start (artificially or not) to depend on Vista.

There's some kernel improvements I certainly wouldn't mind, but they're bogged down by all the crap that's been added to the GUI, Vista is such a pig

Carol Haynes · « **Reply #47 on:** November 21, 2007, 05:44 PM »

This poses the question, why move to Vista with Windows 7 down the road?
-Lashiec (November 21, 2007, 03:25 PM)

Because Windows 7 will be 5 years late, all the promised new stuff will be lost/forgotten and there will be even more DRM crap and you will need a second mortgage for the amount of hardware required to run Word 2013 at half the speed of Word 2000. .Net framework will require 5Gb of RAM to itself because there will be about 15 versions all trying to be be RAM resident simultaneously. Never mind by then you might get Explorer 7.1 and Windows Media Player 12.

Josh · « **Reply #48 on:** November 21, 2007, 05:45 PM »

Carol, I've brought this point up time and time again. WHAT DRM CRAP? The only DRM I've seen is for HD Content and playback over a video card which requires HDCP support. Other than that, I've not seen any DRM problems in vista.

Ralf Maximus · « **Reply #49 on:** November 21, 2007, 05:46 PM »

This poses the question, why move to Vista with Windows 7 down the road?
-Lashiec (November 21, 2007, 03:25 PM)

Because Windows 7 will be 5 years late, all the promised new stuff will be lost/forgotten and there will be even more DRM crap and you will need a second mortgage for the amount of hardware required to run Word 2013 at half the speed of Word 2000. .Net framework will require 5Gb of RAM to itself because there will be about 15 versions all trying to be be RAM resident simultaneously.
-Carol Haynes (November 21, 2007, 05:44 PM)

Ah Carol, ever the optimist. :-)