Main Area and Open Discussion > General Software Discussion

Maybe Vista doesn't suck?

<< < (7/21) > >>

Ralf Maximus:
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)
--- End quote ---

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:
@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  :o
-Darwin (November 19, 2007, 07:59 AM)
--- End quote ---

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:
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:
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.net/reference/articles/article2419.asp
http://www.viva64.com/articles/The_Peculiarities_of_Development_of_64-bit_Applications.html
http://www.viva64.com/articles/Application_port_to_64-bit_platforms_or_never_cackle_till_your_egg_is_laid.html
http://www.viva64.com/articles/Driver_Development_for_Windows_64-bit.html

Ralf Maximus:
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page