struggling with VISTA 64-bit

[Patrice Terrier]

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

Code Select Expand

' 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.

[José Roca]

 
Don't know if this will be the problem, but the LVITEM structure for Vista has two members more:

Code Select Expand


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


[Patrice Terrier]

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

and look at these comments (bottom of the page)

I Tried that with vista 64 (32 bit Compiler) but SendMessage(LVM_GETITEMTEXT...) returns empty item label strings. Does anyone have a solution for that?

Just 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.

 

[Patrice Terrier]

Nobody else using a 64-bit OS?

[Petr Schreiber]

Hi Patrice,

no, I know only few Linuxers running 64bit version of their system.

Regarding 32bit on 64bit:

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

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.

[Patrice Terrier]

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. 

[Charles Pegge]

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.

[Patrice Terrier]

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 !!!

[Patrice Terrier]

Task manager under VISTA 64-bit

See the *32 that denotes a 32-bit application.

[Petr Schreiber]

Hmm,

I didn't know that, quite a problem
Did you sent suggestion to PB support for 64bit compiler?

[Eros Olmi]

I wonder why MS added a piece of string in the process name instead of having a new dedicated column for "*32".

[Patrice Terrier]

I 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.

[Patrice Terrier]

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?

[Edwin Knoppert]

>will be yours soon too
?
Elaborate please.

[Patrice Terrier]

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.