get command line - 64 bit - help with function declarations

[syswizard]

Although I had these command line functions working fine under windows 32 bit, when I tried them on a 64 bit win server installation,
they returned nothing. I did some research, but after making the modifications below, it still did not work.
I start to get returned strange results of ascii characters.
Does anyone know the correct declarations for the below functions ?
Also, do I have to qualify these with a WIN64 directive if-statement ? Or will these work as-is in the Win32 environment.
The one that I am definitely not sure about is the lstrlen function...does it return a LongPtr ?
It should if it's needed in the call to CopyMemory.

Declare PtrSafe Function GetCommandLine Lib "kernel32" Alias "GetCommandLineW" () As String
Declare PtrSafe Function GetCommandLineA Lib "kernel32" () As Long
Declare PtrSafe Function lstrlen Lib "kernel32" Alias "lstrlenW" (ByVal lpString As Long) As Long
Declare PtrSafe Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (MyDest As Any, MySource As Any, ByVal MySize As LongPtr)

Private Function CmdLineToStr() As String

Dim Buffer() As Byte
Dim strlen As Long
Dim CmdPtr As Long

CmdPtr = GetCommandLine()
If CmdPtr > 0 Then
strlen = lstrlenW(CmdPtr) * 2
If strlen > 0 Then
ReDim Buffer(0 To (strlen - 1)) As Byte
CopyMemory Buffer(0), ByVal CmdPtr, strlen
CmdLineToStr = Buffer
End If
End If

End Function

Public Function GetCmdLine() As String
'
' This is a new implementaton; the above did not work in Win64
'
Dim CmdStr As Long
Dim strlen As Long
Dim Buffer As String

'Get a pointer to a string, which contains the command line
CmdStr = GetCommandLineA
'Get the length of that string
strlen = lstrlenW(CmdStr)
'Create a buffer
Buffer = String(strlen, Chr$(0))
'Copy to the buffer
CopyMemory ByVal Buffer, ByVal CmdStr, strlen

GetCmdLine = Buffer

End Function

[HansV]

Do you need to run the code in Excel 2007 or before? Both the 32-bit and 64-bit versions of Excel 2010 and later recognize PtrSafe and LongPtr, and will handle them correctly. But Excel 2007 and before don't "know" them, so you'd need to use conditional compilation.

[syswizard]

Thanks Hans....it's 2010. The problem is confirming which functions need modified to use LongPtr vs. Long.
There was very little documentation on the lstrlen function...and isn't it strange that it returns a long, but is referenced in another function that is declared LongPtr ?

[HansV]

You can download a complete reference: Office 2010 Help Files: Win32API_PtrSafe with 64-bit Support - when you install this, it can be found in C:\Office 2010 Developer Resources\Documents\Office2010Win32API_PtrSafe.

A list of functions and structures that have been changed for 64-bit use: 64-bit Windows.

(Source: Jan Karel Pieterse's website)

[syswizard]

Yep - already had that. Once again, I believe this is the problem:
Declare PtrSafe Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any, Source As Any, ByVal Length As LongPtr)
Declare PtrSafe Function lstrlen Lib "kernel32" Alias "lstrlenA" (ByVal lpString As String) As Long

The problem is the CopyMemory changed from Long to LongPtr but the lstrlen return arg did NOT change.

That could explain my problem. LongPtr resolves to 64 bits under Win64.
re: "from...." http://msdn.microsoft.com/en-us/library ... e.15).aspx

In summary, for code to work in 64-bit versions of Office, you need to locate and modify all existing Declare statements to use the PtrSafe qualifier. And you need to locate and modify all data types within these Declare statements that reference handles or pointers to use the new 64-bit compatible LongPtr type alias, and types that need to hold 64-bit integrals with the new LongLong data type. Additionally, you must update any user defined types (UDTs) that contain pointers or handles, and 64-bit integrals to use 64-bit data types and verify all variable assignments are correct to prevent type mismatch errors.

[HansV]

Are you actually running 64-bit Office 2010?

[syswizard]

Exactly....I just discovered...NO, it's the 32 bit version running on the 64 bit Windows O/S.
Apparently, the LongLong or LongPtr doesn't resolve to 64 bits unless you have both Office and Windows at 64 bits.
That was always something I wondered about.
Still, this does not explain why the function calls are not working as they did under 32 bit windows.

[HansV]

Even on 64-bit Windows, you should use the 32-bit versions of the API calls in 32-bit Office.
But perhaps the code doesn't work because you're using it on Windows Server - Office is not intended to be used on Windows Server...

[syswizard]

re: "Office not on Windows Server".
Where did you hear that ?
Windows is Windows as far as I am concerned.
I doubt seriously they would change core functionality like the command line between workstation and server editions.

Next week, I am going to re-test this on Win 7 and try to get it to work there.
Then I'll port that to Windows Server 2008....and see if it works.

[HansV]

One of the reasons that Office applications are dangerous to use on a server is that they may pop up a modal dialog and wait until the dialog is dismissed. Not a good idea on a server...