Main Area and Open Discussion > General Software Discussion
Any XP users switching to Windows 7 yet?
MilesAhead:
It doesn't sound appealing. Like I say, they're a step behind.
I looked at Lazarus and even there, dialog paint routines that I used in Delphi 5 looked washed out with that IDE's gui libraries. It just doesn't look the same. Setting up a bunch of environment variables and messing around for 2 days is old. 64 bit is here!! They need to get on the stick with one click install, drag & drop development of stand-alone executable applications.
f0dder:
It doesn't sound appealing. Like I say, they're a step behind.-MilesAhead (November 20, 2009, 07:38 PM)
--- End quote ---
I guess Microsoft's reasoning is that 64bit support is a "pro" feature that "hobbyists" don't need - if you're producing 64bit applications, you're probably doing "serious business" and can afford the full compiler package. I don't necessarily agree, but I think it's fair enough of MS to impose a restriction like that... and after all, you do get the full 64bit compiler in the PlatformSDK.
Whether the strategy hinders the adoption of 64bit as the main platform... *shrug*
MilesAhead:
I'm not just talking about MS. I don't see any compilers coming along as one would expect in 64 bit flavors.
It seems like the only people trying to do it are open source programmers. That doesn't usually imply it's gonna' happen real fast. :(
Stoic Joker:
Hold on, I'm not familiar about this, can you clarify? What is the myth? That 32-bit applications suffer in performance in 64-bit OS? Or that the difference in performance in general for 64-bit OS's is negligible relative to 32-bit? Because I was considering moving to Windows 7 64-bit and taking advantage of the additional RAM.
-superboyac (November 19, 2009, 03:58 PM)
--- End quote ---
The myth is that 32 bit programs run slower under 64 bit OS's. As you can see, three of us have not really seen that in real world usage (bar f0dder's Foxit Reader example).
-Darwin (November 19, 2009, 04:31 PM)
--- End quote ---
Make that four of us ... I've been x64 for a few years and haven't seen foot dragging at all.
@MilesAhead - The thing is if you don't really need a program to be 64-bit, then compiling it that way is just an academic exercise/waste.
Let's use T-Clock as an example; there is both a 32bit & a 64bit version of the program compiled with MSVS2005 . Both use the exact same source code but are referenced under different project names in the same solution (both are running on Win7):
x86: Memory (Private Working Set) 1,508
x64: Memory (Private Working Set) 2,188
...Which makes the question, why gobble up a bunch of memory that you don't need & can't use for program X. T-Clock has to be 64 bit because you can't inject a 32 bit (clock) hook into a 64 bit (system tray) process. None of my other software is 64 bit as there is just no (way to justify the memory usage waste) need for it.
Eóin:
The thing is if you don't really need a program to be 64-bit, then compiling it that way is just an academic exercise/waste.
... [snip] ...
None of my other software is 64 bit as there is just no (way to justify the memory usage waste) need for it.
-Stoic Joker (November 21, 2009, 08:21 AM)
--- End quote ---
Well there is the rarely seen processor efficiency. In theory x64 apps should run a bit faster as they can avail of more recent processor instructions which 32bit apps usually avoid to maintain backwards compatibility with older CPUs. Exactly how that manifests in day to day applications would be debatable.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version