My new notebook is provided with VISTA 64-bit and while checking all my projects with it, i found that "Of The Bay" is not able to retrieve anymore the name of the Desktop icon.
I am using OpenProcess to retrieve the data from the desktop listview, using:
CALL SendMessage(hListView, %LVM_GETITEMTEXT, K, lpItem)
CALL SendMessage(hListView, %LVM_GETITEMPOSITION, K, lpPosition)
the position works fine, however LVM_GETITEMTEXT or LVM_GETITEMTEXTW always return a NULL string, causing me the havoc.
Here is the code i am using to check for this problem
' On VISTA 64-bit (and with the PB9 32-bit compiler) SendMessage(LVM_GETITEMTEXT...) returns an empty item label strings.
' The same works just fine on XP and VISTA 32-bit
'
' Note: I am using José Roca's include files
'
#COMPILE EXE "CHKVISTA64.exe"
#INCLUDE "Win32API.inc"
#INCLUDE ONCE "ListViewCtrl.INC"
'// Main entry point
FUNCTION WINMAIN (BYVAL hInstance AS LONG, _
BYVAL hPrevInstance AS LONG, _
BYVAL lpCmdLine AS ASCIIZ PTR, _
BYVAL iCmdShow AS LONG) AS LONG
LOCAL hProgMan, hListView AS DWORD
LOCAL K, nItemCount AS LONG
hProgMan = FindWindow("Progman", "Program Manager")
hListView = FindWindowEx(hProgMan, 0, "SHELLDLL_DefView", "")
hListView = FindWindowEx(hListView, 0, "SysListView32", "FolderView")
nItemCount = SendMessage(hListView, %LVM_GETITEMCOUNT, 0, 0)
IF nItemCount THEN
LOCAL dwProcessId, hProcess, dwSize, lpData AS DWORD
CALL GetWindowThreadProcessId(hListView, dwProcessId)
hProcess = OpenProcess(%PROCESS_VM_OPERATION OR %PROCESS_VM_READ OR %PROCESS_VM_WRITE, %FALSE, dwProcessId)
IF hProcess THEN
'// Compute the size of our reserved memory buffer
dwSize = SIZEOF(POINTAPI) + SIZEOF(LVITEM) + %MAX_PATH * 2
lpData = VirtualAllocEx(hProcess, BYVAL %NULL, dwSize, %MEM_COMMIT, %PAGE_READWRITE)
IF lpData THEN
LOCAL lvi AS LVITEM
LOCAL szTxt AS ASCIIZ * (%MAX_PATH * 2) ' Allow room for unicode
LOCAL p AS POINTAPI
LOCAL lpPosition, lpItem, lpText AS DWORD
lpPosition = lpData
'// Setup pointers
lpItem = lpData + SIZEOF(POINTAPI)
lpText = lpData + SIZEOF(POINTAPI) + SIZEOF(LVITEM)
IF nItemCount > 3 THEN nItemCount = 3 '// 3 is enough to see the problem
FOR K = 0 TO nItemCount - 1
'// Init LVITEM structure and copy it to our reserved memory buffer
lvi.mask = %LVIF_TEXT
lvi.iItem = K
lvi.iSubItem = 0
lvi.pszText = lpText
lvi.cchTextMax = %MAX_PATH * 2
CALL WriteProcessMemory(hProcess, lpItem, lvi, SIZEOF(LVITEM), 0)
'// Get text label *** THIS ONE FAILS ON VISTA 64-bit ***
szTxt = ""
CALL SendMessage(hListView, %LVM_GETITEMTEXT, K, lpItem)
CALL ReadProcessMemory(hProcess, lpText, szTxt, SIZEOF(szTxt), 0)
'// Get x,y location
CALL SendMessage(hListView, %LVM_GETITEMPOSITION, K, lpPosition)
CALL ReadProcessMemory(hProcess, lpPosition, p, SIZEOF(POINTAPI), 0)
msgbox "The label string is """ + szTxt + """" + $cr + "x, y location:" + str$(p.X) + "," + str$(p.Y)
NEXT
'// Freeup memory
CALL VirtualFreeEx(hProcess, lpData, 0, %MEM_RELEASE)
END IF
'// Close process
CALL CloseHandle(hProcess)
END IF
END IF
END FUNCTION
If you have some suggestion that would help me to solve this problem i would be glad to read it.
I have been GooGling on the net, using seach "Desktop icon LVM_GetItemText", i found some code, but they are all doing the same than me.
:-[
Don't know if this will be the problem, but the LVITEM structure for Vista has two members more:
TYPE LVITEM_V6
mask AS DWORD ' UINT mask
iItem AS LONG ' int iItem
iSubItem AS LONG ' int iSubItem
state AS DWORD ' UINT state
stateMask AS DWORD ' UINT stateMask
pszText AS ASCIIZ PTR ' LPSTR pszText
cchTextMax AS LONG ' int cchTextMax
iImage AS LONG ' int iImage
lParam AS LONG ' LPARAM lParam
'#if (_WIN32_IE >= 0x0300)
iIndent AS LONG ' int iIndent
'#endif
'#if (_WIN32_WINNT >= 0x501)
iGroupId AS LONG ' int iGroupId
cColumns AS DWORD ' UINT cColumns // tile view columns
puColumns AS DWORD PTR ' PUINT puColumns
'#endif
'#if _WIN32_WINNT >= 0x0600
piColFmt AS LONG PTR ' int*
iGroup AS LONG ' int // readonly. only valid for owner data.
'#endif
END TYPE
José,
See this thread
http://www.codeproject.com/KB/threads/int64_memsteal.aspx?display=PrintAll&fid=29535&df=90&mpp=25&noise=3&sort=Position&view=Quick&select=2558283 (http://www.codeproject.com/KB/threads/int64_memsteal.aspx?display=PrintAll&fid=29535&df=90&mpp=25&noise=3&sort=Position&view=Quick&select=2558283)
and look at these comments (bottom of the page)
QuoteI Tried that with vista 64 (32 bit Compiler) but SendMessage(LVM_GETITEMTEXT...) returns empty item label strings. Does anyone have a solution for that?
QuoteJust found out how to solve that:
The desktop listviews address space in Vista 64 of course is in 64-bit address space and the 32-bit app uses 32-bit pointers when reading and writing the processes foreign memory. Compiling the app with a 64-bit compiler fixes that problem
Unfortunatly i can't check it myself, because PB doesn't offer yet a 64-bit compiler.
:(
Nobody else using a 64-bit OS?
???
Hi Patrice,
no, I know only few Linuxers running 64bit version of their system.
Regarding 32bit on 64bit:
Quote
Many programs designed for a computer running a 32-bit version of Windows will work on a computer running 64-bit versions of Windows without any changes. However, in some cases there might be differences in performance. If a 32-bit program uses embedded drivers, the drivers might not work in the 64-bit environment. If you have a 64-bit computer, it's best to run programs designed to run on a 64-bit computer.
http://windowshelp.microsoft.com/Windows/en-us/help/41531554-d5ef-4f2c-8fb9-149bdc5c8a701033.mspx
... so I am confused, as what you describe is not performance hit but serious problem, hmm.
I also thought Vista 64 runs 32bit exes in emulation mode, which should protect you from problem with pointers, weird.
From here: http://www.computerperformance.co.uk/ezine/BestPractice/BestPractice148.htm
Quote
The Secret Compatibility Factor
Programs must be installed afresh on your 64-bit Vista computer; just copying and pasting an application's files from an old 32-bit computer gives the illusion of incompatibility. What I find is that if you let the 64-bit operating system handle the installation from scratch, then its built-in emulation deals with 32-bit programs easily.
The secret factor is that when 64-bit systems were designed, they knew that 32-bit compatibility would be an important requirement, thus the operating system is literally programmed to deal with installing programs that were designed with 32-bit operating systems in mind. One encouraging sign is that Vista has a special folder called 'Program Files (x86)'. This is an addition to the plain 'Program Files' folder for 64-bit programs.
???
As per se, the problem seems to occur only when a 32-bit app uses 32-bit pointers to read and write a 64-bit foreign process memory. Compiling the app with a 64-bit compiler fixes that problem, but unfortunatly PB has not yet a 64-bit option.
Apart from OS call differences, there are changes in some of the opcodes: The single byte INC and DEC (40-4F)disappear and their opcodes are reused as RAS (64 bit) instruction prefixes. PUSH and POP use 8 bytes on the stack instead of 4. These are some of the more important differences that necessitate recompilation for 64 bit mode.
Yes, "thunking" between application can only be done if they are both using the same memory model 32 or 64-bit.
In my case "Of The Bay" is a 32-bit application while the "Program manager" is 64-bit ...
I shall see if i can find a work arround, anyway this is a major issue you should be aware of, because most of the new computers are now provided with VISTA 64 !!!
???
Task manager under VISTA 64-bit
See the *32 that denotes a 32-bit application.
(http://www.zapsolution.com/pictures/processus.jpg)
Hmm,
I didn't know that, quite a problem :(
Did you sent suggestion to PB support for 64bit compiler?
I wonder why MS added a piece of string in the process name instead of having a new dedicated column for "*32".
QuoteI didn't know that, quite a problem
Did you sent suggestion to PB support for 64bit compiler?
Yes, i did it, but no answer yet, Bob is probably as much upset than me.
???
I still have no answer to my problem (will be yours soon too) of mixing 32-bit and 64-bit applications.
Because they can't be mixed together, the only solution would be to have a compiler that would let us select the 32 or 64-bit target.
Which true compiler you know (except VISUAL STUDIO) that offers already such feature?
>will be yours soon too
?
Elaborate please.
As a third party DLL provider it is important to provide the DLL in 64-bit, when it is to be used by a 64-bit application.
32-bit application can only call 32-bit DLL
64-bit application can only call 64-bit DLL
and when you have to perform interoperability with another application written in 64-bit, you can't do it from 32-bit because the pointer's adress space is not the same.
QuoteWhich true compiler you know (except VISUAL STUDIO) that offers already such feature?
C Compilers
Pelle's C (http://www.smorgasbordet.com/pellesc/)
GCC
Assemblers
PoAsm (comes with Pelle's C)
GoAsm (http://www.jorgon.freeserve.co.uk/)
Who has ever done pointer marshalling with Pb9?
I have no idea how to do this myself.
:(
Hi Patrice,
maybe wrong idea, but what about using QUADS (64bit opposing to 32bit DWORD) to store pointer?
I guess this alone would not be sufficient, but could be part of the right path?
Maybe using something like:
%TARGET_BITS = 32
#IF %TARGET_BITS = 32
MACRO wHANDLE = DWORD
MACRO NAKEDPOINTER = DWORD
#ELSE
MACRO wHANDLE = QUAD
MACRO NAKEDPOINTER = QUAD
#ENDIF
... could be good practise? Don't know...
Petr
Petr,
Unfortunatly this couldn't be as simple as this.
I have checked several 64-bit application(s) with 32-bit DLL(s) and i always get an error message telling me that this couldn't be done.
...
The macros are useful when you have to compile the same source with a 32 bit or 64 bit compiler, but a 32 bit application can't use 64 bits DLLs and 64 bit applications can't use 32 bit DLLs.
32 bit applications can use 64 bit COM out of process servers and 64 bit applications can use 32 bit out of process servers, but with in-process servers you will have the same problem that with standard DLLs.
Yes "le serpent se mord la queue" (snake is biting his tail), i wouldn't have to wait too long before PB-64 is coming out, or i'll have no other choice than moving all my code to C, fortunatly i wrote it in pure SDK.
:'(
For those, like me, who do not know exaclty what a "thunking mechanism" means,
here is the begining of an answer:
http://www.codeproject.com/KB/cpp/Thunk_uses.aspx (http://www.codeproject.com/KB/cpp/Thunk_uses.aspx)
Added:
http://blogs.sepago.de/nicholas/2008/03/13/jailed-32-bit-processes-on-windows-x64/ (http://blogs.sepago.de/nicholas/2008/03/13/jailed-32-bit-processes-on-windows-x64/)
Added:
http://www.ddj.com/hpc-high-performance-computing/184401966 (http://www.ddj.com/hpc-high-performance-computing/184401966)
Added:
http://www.mazecomputer.com/sxs/help/64bitwindows.htm (http://www.mazecomputer.com/sxs/help/64bitwindows.htm)
Added:
http://msdn.microsoft.com/en-us/library/aa384249(VS.85).aspx (http://msdn.microsoft.com/en-us/library/aa384249(VS.85).aspx)
I did further test on VISTA 64-bit, and i encountered a strange problem with the old GDI StretchBlt API that sometimes failed without any error with 32-bit bitmap (looks like an Alpha channel problem), while using the Alphablend API (in the same situation) always works fine.
...
@Patrice,
I guess you are on the wrong road.
In Vista 64 or not, applications can only sent messages to Applications when they have the same rights.
Just start your application "as Admin" and see what happens.
I the same way you may have trouble to read colour-values from windows, which are from higher-righted processes.
This is part of the new UAC-Safety-System
Theo,
Quote
Topic Summary
Posted on: Today at 06:58:38 PMPosted by: Theo Gottwald
Insert Quote
I guess you are on the wrong road.
In Vista 64 or not, applications can only sent messages to Applications when they have the same rights.
Just start your application "as Admin" and see what happens.
I the same way you may have trouble to read colour-values from windows, which are from higher-righted processes.
This is part of the new UAC-Safety-System
Well, i think I am (already) aware of this ;)
Added:
I have used the VISTA 32-bit since almost two years in administrator mode, and with the UAC being turned off.
Read the whole thread about the issues between 32-bit and 64-bit. Search also on Google for mixing X64 with 32-bit applications.
...
ok, was just a guess. I think i should try next time first :-).
Other VISTA 64 issue(s), i have encountered:
1 - I am unable to remove the small arrow overlay from the desktop shorcuts.
2 - I am unable to print (with my wi-fi HP Photosmart C 6180) from IE7, while it does just fine with FireFox.
Note: I didn't had these problems with VISTA 32-bit
...
Do we need a 64 bit compiler?
Theo,
YES, we need a 64-bit compiler to work with those Windows OS runing in X64 mode(XP, 2005, VISTA and now Windows 7).
Added:
So far, i do not need "bells and whistles", if this could help to produce it faster ;)
I just downloaded and installed the C# VS2008 Express Edition, to try it with my PowerBASIC GDImage.dll.
Unfortunatly it doesn't work with it, because i am on VISTA x64 and the VS2008 generates x64 code instead of x32, and so far i didn't find how to configure the Express Edition to generate a 32x target solution.
If you know how to setup the VS2008 Express Edition to target the x32 platform, i would be glad to learn about it.
...
Quote from: Patrice Terrier on February 10, 2009, 02:54:43 PM
I just downloaded and installed the C# VS2008 Express Edition, to try it with my PowerBASIC GDImage.dll.
Unfortunatly it doesn't work with it, because i am on VISTA x64 and the VS2008 generates x64 code instead of x32, and so far i didn't find how to configure the Express Edition to generate a 32x target solution.
If you know how to setup the VS2008 Express Edition to target the x32 platform, i would be glad to learn about it.
...
As I mentioned on the Pb Forum: Unless your really need 64bit apps install the 32bit version??
James
Most people switching to Vista, use Vista 64.
Just like me. The reason is that Vista32 does not really make sense compared to XP or even W2k.
Another thing is, that Memory is cheap actually, it can only be used with a 64 bit OS if its more the 4 GB.
But then XP64 is the worse choice then Vista 64 and as such 64 bit is definitely coming.
I also would really prefer to get a PB 64 then to have to switch over to C like languages.
I hope Bob reads this and has an idea how to automatically convert his ASM to ASM 64 :-).
I'd prefer, if he would drop the PB Console Compiler and rather make a 32- and a 64 bit Line.
QuoteI'd prefer, if he would drop the PB Console Compiler and rather make a 32- and a 64 bit Line.
Me too, and i would rather see enhancement to the compiler itself than further DDT API encapsulation.
We are not all rookies, and we need to have the same compiler facilities than our C competitors.
We have asked for years static linking, without success, but we were able to use include files with conditional compiling as a work around. However there is no way for us to solve the x64 issue without a 64-bit compiler.
Bob, if you read this, please listen to us, because we need it right now, thank you!
...
QuoteIf you know how to setup the VS2008 Express Edition to target the x32 platform, i would be glad to learn about it.
Patrice,
Maybe this is what you are looking for?
http://visualstudiohacks.com/articles/visual-studio-net-platform-target-explained/
[edit] It looks like the Visual C# Express Edition doesn't have the different output options.
[edit] Note: Visual C++ Express Edition does have the different output options.
Greg,
I have uninstalled the VS2008 Express Edition, and reinstalled the VS2005 Standard Edition that allows me to produce either x64 or x32 managed code.
I didn't thought i will encounter so many problems with x64/x32 compability when i bought my new laptop HP HDX 18, but the good thing is that now i can experience by myself those problems ...
Before that, i never heard of Wow64 ;)
...
I'm just starting to learn about x64 myself. I installed the Windows 7 Beta 64-bit as a dual-boot and it's the first 64-bit OS I have used. The only problem I have run into is Adobe Flash Player doesn't have a version for 64-bit browsers. So I run 32-bit Firefox.
I have been using Pelle's C and GoAsm, which both support x64. It's like starting all over again with the assembler part, new registers, new calling-convention etc.
It's interesting.
Greg,
QuoteIt's like starting all over again with the assembler part, new registers, new calling-convention etc.
64-bit computers and 64-bit OS have been there already for a few years, but 2009 is the first year where most of the new computers are sold pre-installed with both of them.
On another forum you can read:
QuotePowerBASIC is fully compatible with every 32-bit and 64-bit version of Windows.
This is true, but there is no way to mix 32/64-bit EXE/DLL code inside of the same application.
The only solution is to use a 64-bit DLL to work with a 64-bit EXE, and a 32-bit DLL to work with a 32-bit EXE.
...
Patrice,
Yep, 64-bit Windows is just now becoming mainstream.
QuoteThe only solution is to use a 64-bit DLL to work with a 64-bit EXE, and a 32-bit DLL to work with a 32-bit EXE.
You are right.
I would guess that PowerBASIC is working on a 64-bit output option.
Here is another 64-bit issue i have been faced with, while trying to perform a screen shot of the Desktop.
On 32-bit OS it has been working fine for years, but on 64-bit it does nothing...
SUB ScreenCaptureToBackground()
LOCAL SysXRes AS LONG, SysYRes AS LONG, gCtrl AS LONG, hDeskTop AS LONG, hDCSrce AS LONG
SysXRes = GetSystemMetrics(%SM_CXSCREEN)
SysYRes = GetSystemMetrics(%SM_CYSCREEN)
gCtrl = GetDlgItem(hMain, %ID_CTRL)
CALL ZI_CreateImageBackground(gCtrl, SysXRes, SysYRes)
hDeskTop = GetDesktopWindow(): hDCSrce = GetWindowDC(hDeskTop)
CALL BitBlt(ZI_GetDC(gCtrl), 0, 0, SysXRes, SysYRes, hDCSrce, 0, 0, %SRCCOPY)
CALL ReleaseDC(hDeskTop, hDCSrce)
END SUB
The only solution i found so far, is to mimic a hard-copy "print screen" and paste the bitmap from the clipboard, but perhaps you may have another suggestion?
...
Ok, here is the solution, we must add the code shown below in red, to setup the Alpha Channel that is lost during the Wow64 translation between 64/32-bit.
LOCAL pBits AS BYTE PTR, bm AS BITMAP, P AS LONG
CALL GetObject(GetCurrentObject(ZI_GetDC(gCtrl), 7), SIZEOF(bm), bm)
pBits = bm.bmBits
FOR P = (bm.bmWidth * bm.bmHeight) TO 1 STEP - 1
@pBits[3] = 255 ' // Setup the opacity level
pBits = pBits + 4
NEXT
SUB ScreenCaptureToBackground()
LOCAL SysXRes AS LONG, SysYRes AS LONG, gCtrl AS LONG, hDeskTop AS LONG, hDCSrce AS LONG
SysXRes = GetSystemMetrics(%SM_CXSCREEN)
SysYRes = GetSystemMetrics(%SM_CYSCREEN)
gCtrl = GetDlgItem(hMain, %ID_CTRL)
CALL ZI_CreateImageBackground(gCtrl, SysXRes, SysYRes)
hDeskTop = GetDesktopWindow(): hDCSrce = GetWindowDC(hDeskTop)
CALL BitBlt(ZI_GetDC(gCtrl), 0, 0, SysXRes, SysYRes, hDCSrce, 0, 0, %SRCCOPY)
LOCAL pBits AS BYTE PTR, bm AS BITMAP, P AS LONG
CALL GetObject(GetCurrentObject(ZI_GetDC(gCtrl), 7), SIZEOF(bm), bm)
pBits = bm.bmBits
FOR P = (bm.bmWidth * bm.bmHeight) TO 1 STEP - 1
@pBits[3] = 255 ' // Setup the opacity level
pBits = pBits + 4
NEXT
CALL ReleaseDC(hDeskTop, hDCSrce)
END SUB
This is another example showing the reason why we need a true 64-bit compiler!
QuoteThis is another example showing the reason why we need a true 64-bit compiler!
I agree on this. Do you beleive there is any hope?
Theo,
As long as i am the only one to complain, i think there is not much hope.
It reminds me the same situtation i have been faced with, when i was pioneering VISTA.
Looks like most programmers are very relunctant to learn something new, because of the extra effort, however it is the only way to stay in the race, and the older you are, then the more relunctant of course ;)
A french papy boomer that doesn't want to surrender ;D
...
Quote from: Patrice Terrier on March 01, 2009, 10:04:16 AM
Looks like most programmers are very relunctant to learn something new, because of the extra effort, however it is the only way to stay in the race, and the older you are, then the more relunctant of course ;)
Well, do not jump to the conclusion on the situations of others.
For example, in my case I mainly use PB for my company programming (and of course my project). And for many other people I know working in different companies:
WE SIMPLY JUMPED VISTA completely ! Can you imagine 64 bit and all the problems it can carry about company applications compatibility?
I've bought hundred of computers for my company users and for all of them we downgraded to XP. We just buy professional line HP computers and all of them come to our office already with XP and Vista installed and downgrade is just a snap.
I think this happen all over the world and Vista was mainly sold in bundle with the hardware only due to contracts manufacturers have with MS.
This just to say that for a big part of the world Vista (especially inside commercial companies) and 64 bit OS problem simply does not exists and so for programmers working for that companies.
I'm quite sure PB is working in this issue but with their way and their time schedule.
I already tested Windows 7 and I feel this time things will be different. Windows 7 seems what Vista should have been since the beginning. I'm sure you will have greater chance.
Ciao
Eros
Eros,
Windows 7, is just a new "mouture" of VISTA as far as we are speaking of the DWM graphic engine and the 64-bit version.
Fortunatly, what i have learned about VISTA would apply the same to Windows 7 at least for what i am concerned with.
The problem on Windows 7 with the 64-bit version are still the same than on VISTA 64-bit, as long as you don't use a 64-bit compiler, at least with the current W7 beta.
...
Eros,
QuoteWE SIMPLY JUMPED VISTA completely !
Well, that means that we are not targeting the same audience at all.
Myself, as a third party addon provider, i am faced with different platforms, most of them like DotNET and WinDev, running and using the latest technologies.
Myself, as mutimedia programmer, i have to deal with end user who buy their computers either on the Internet or in super-store, and all these computers are being sold with VISTA pre-installed...
Moreover, for people like myself,
VISTA is the best graphic platform ever done for PC! ...
Hey Patrice I perfectly know and I know Vista (in its all versions) is a great OS.
Do not look at the problem from the key hole. Problem is much bigger than 64 bit or compatibility.
You need to think to user perceptions and reactions. And when user perceptions is negative (for whatever reasons), companies stay at the window looking and not upgrading. Companies do not have time to solve OS problems, it is already hard to lose time to solve application problems.
And if companies do not install the latest MS OS, than MS has problems! And if companies do not install Vista that also demands a new quite powerful hardware that there will not be so much 64bit CPU
Why MS had to develop a new Vista Clone? Just to fight user perception and give the impression it is another OS following user requests. Same content different box.
To me Vista is dead. But this is not so negative because it will give time to have a great demand of latest CPU.
Eros,
QuoteDo not look at the problem from the key hole
I don't think i am looking the problem from the key hole (look at my previous answer).
We don't have all the same needs and targets, that is a fact.
I was not hable myself to ignore VISTA, and i had no choice, when you are working in the programming industry you must follow the standard and use the same tools than your customers, easy to understand, no?
...
Yes easy to understand but it is just an isle: your customers.
Vista is not "the standard" and 64 bits are not "the standard".
They are an "avantguard" of something that the rest of the world will follow but not now and not now that economy is shrinking.
I'm sure you will find many situations where you need 64 bit but on the whole, that situations will remain very insignificant and only significant in a specific area: their specific areas.
Anyhow, I'm 100% sure you are on the right side.
Eros,
QuoteYes easy to understand but it is just an isle: your customers.
My customers are making my living, that says all :)
...
Eros
QuoteI'm sure you will find many situations where you need 64 bit but on the whole.
I had no choice, my new HP HDX 18 laptop, comes with it pre-installed because the processor is an Intel Core 2 Duo P8400 (2.26 Ghz) that is a 64-bit processor with 4 Gb ram.
My sister just bought a TOSHIBA QOSMIO that was also provided with the same 64-bit processor and 64-bit VISTA.
And the same for my son that bought a 16 inches HP notebook, one month ago.
And you know what, they are using them to surf on the Internet, download and play AVI/DivX movies, play audio, store and edit photography, watch/record TNT TV, type their letters and check their bank acount with the Open Office suite, and that's all!
...