-
Oct 13th, 2024, 07:22 PM
#81
Thread Starter
Fanatic Member
Re: Compatibility of 32-bit VB6 Applications with 64-bit SAPI
This is so frustrating.
It does not matter where I put the proxy/moniker. Obviously I have to somehow deal with the manifest issue, but I don't see how.
Here is my app's manifest:
Code:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" >
<assemblyIdentity version="1.0.1.0" processorArchitecture="X86" name="Application" type="win32" />
<description>Theme&Trust </description>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*">
</assemblyIdentity>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="true" />
</requestedPrivileges>
</security>
</trustInfo>
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>false</dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>
Can somebody tell me what I must do about a possible manifest for the proxy / moniker?
-
Oct 13th, 2024, 07:36 PM
#82
Re: Compatibility of 32-bit VB6 Applications with 64-bit SAPI
You don't need another manifest for the proxy, you just need to start it elevated as well (using ShellExecuteW with the "runas" verb).
-
Oct 13th, 2024, 08:43 PM
#83
Thread Starter
Fanatic Member
Re: Compatibility of 32-bit VB6 Applications with 64-bit SAPI
I am not starting my application elevated. It is run just normally. No UAC prompt occurs.
What you propose does trigger a UAC prompt:
Code:
Dim lRet&
lRet = ShellExecuteA(0, "runas", uPath, "", uDir, uWindowStyle)
Last edited by tmighty2; Oct 13th, 2024 at 08:48 PM.
-
Oct 14th, 2024, 05:14 AM
#84
Re: Compatibility of 32-bit VB6 Applications with 64-bit SAPI
Using uiAccess="true" is such an oddball case.
I think this flag is meant to allow your app to interact/capture logon screen. Do you need this? Do you write another TeamViewer?
Chances are most/your apps never need uiAccess="true" but it got set "just in case" all the time and now makes problems.
cheers,
</wqw>
-
Oct 14th, 2024, 05:57 AM
#85
Re: Compatibility of 32-bit VB6 Applications with 64-bit SAPI
In principle uiAccess allows drag drop between elevated and unelevated. I've never gotten it to work, even after jumping through all the hoops and verifying it was in fact enabled for the token (GetTokenInformation/TokenUIAccess).
-
Oct 14th, 2024, 01:25 PM
#86
Thread Starter
Fanatic Member
Re: Compatibility of 32-bit VB6 Applications with 64-bit SAPI
Yes, I do need uiAccess. It is a virtual keyboard, and it does work for me.
I can confirm that when I set uiAccess=false in my app, then the proxy and everything works fine.
I have not yet figured out how to call the proxy with my app having uiAccess=true.
Last edited by tmighty2; Oct 14th, 2024 at 02:30 PM.
-
Oct 14th, 2024, 02:39 PM
#87
Thread Starter
Fanatic Member
Re: Compatibility of 32-bit VB6 Applications with 64-bit SAPI
Can somebody tell me how to log what is happening?
What I don't understand:
Even when I add a manifest to the proxy with uiAccess=true and code-sign it, it still does not work.
Last edited by tmighty2; Oct 14th, 2024 at 02:47 PM.
-
Oct 14th, 2024, 02:45 PM
#88
Re: Compatibility of 32-bit VB6 Applications with 64-bit SAPI
Originally Posted by tmighty2
Can somebody tell me how to log what is happening?
Did you try both x86 and x64 executables marked uiAccess=true?
Btw, I think uiAccess=true assume elevated execution, whether you get UAC dialog or not the process must be running elevated.
cheers,
</wqw>
-
Oct 14th, 2024, 02:48 PM
#89
Thread Starter
Fanatic Member
Re: Compatibility of 32-bit VB6 Applications with 64-bit SAPI
Yes, I did try that: My app (32 bit) and the proxy (64bit) have uiAccess=true.
I was a bit unclear about what exactely happens in this case:
Shell fails with the error message "Invalid procedure call or argument, err.number: 5"
So my 32bit app is not even able to start the 64bit proxy even though it has the same privileges.
ps: I know that I should perhaps convert the entire project to TB, but I don't have the time and this problem affects more projects, not only this one.
Last edited by tmighty2; Oct 14th, 2024 at 03:09 PM.
-
Oct 14th, 2024, 03:03 PM
#90
Re: Compatibility of 32-bit VB6 Applications with 64-bit SAPI
> So my 32bit app is not even able to start the 64bit proxy even though it has the same privileges.
Can you start your x64 proxy manually, with proper command-line parameters? Does it work then?
cheers,
</wqw>
-
Oct 14th, 2024, 03:20 PM
#91
Thread Starter
Fanatic Member
Re: Compatibility of 32-bit VB6 Applications with 64-bit SAPI
Yes! That works!
Can you suggest what I should do?
Must I start the proxy "externally", meaning NOT by my app and then use it? The problem I see with this is that I can not pass the UUID.
I had tried to start it within my app using CreateProcess, but it failed returning 0, and that was already beyond my understanding, so I did not try that any further.
-
Oct 14th, 2024, 03:26 PM
#92
Thread Starter
Fanatic Member
Re: Compatibility of 32-bit VB6 Applications with 64-bit SAPI
ps: I started the proxy by being a normal user and then opening the commandline and typing
Code:
D:\(...)\twsMoniker64_win64.exe 8b6071b5-c1d3-4a8a-97c8-55f554077f9f
And then I used it in my 32bit VB6 app like this:
Code:
Set m_oProxy64 = GetObject("8b6071b5-c1d3-4a8a-97c8-55f554077f9f")
And the proxy currently has this manifest:
Code:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="true"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
And it is code-signed.
-
Oct 14th, 2024, 08:57 PM
#93
Thread Starter
Fanatic Member
Re: Compatibility of 32-bit VB6 Applications with 64-bit SAPI
I still have not managed to start the proxy from within my app. Thank you for any suggestion how to accomplish that.
This approach fails with error 740 indicating that the app requires elevation:
Code:
Private Declare Function CreateProcess Lib "kernel32" Alias "CreateProcessA" (ByVal lpApplicationName As String, ByVal lpCommandLine As String, lpProcessAttributes As SECURITY_ATTRIBUTES, lpThreadAttributes As SECURITY_ATTRIBUTES, ByVal bInheritHandles As Long, ByVal dwCreationFlags As Long, lpEnvironment As Long, ByVal lpCurrentDirectory As String, lpStartupInfo As STARTUPINFO, lpProcessInformation As PROCESS_INFORMATION) As Long
Private Type SECURITY_ATTRIBUTES
nLength As Long
lpSecurityDescriptor As Long
bInheritHandle As Long
End Type
Private Type STARTUPINFO
cb As Long
lpReserved As String
lpDesktop As String
lpTitle As String
dwX As Long
dwY As Long
dwXSize As Long
dwYSize As Long
dwXCountChars As Long
dwYCountChars As Long
dwFillAttribute As Long
dwFlags As Long
wShowWindow As Integer
cbReserved2 As Integer
lpReserved2 As Long
hStdInput As Long
hStdOutput As Long
hStdError As Long
End Type
Private Type PROCESS_INFORMATION
hProcess As Long
hThread As Long
dwProcessId As Long
dwthreadid As Long
End Type
Private Const CREATE_NO_WINDOW = &H8000000 ' Prevents the command window from appearing
Private Sub pStartProxy()
Dim sAppPath As String
sAppPath = "D:\Dev\Projects\tws64\TB\Build\twsMoniker64_win64.exe"
sAppPath = App.Path & "\twsMoniker64_win64.exe"
Dim sArg$
sArg = "8b6071b5-c1d3-4a8a-97c8-55f554077f9f"
Dim sCmdLine As String
sCmdLine = sAppPath & " " & sArg
Dim si As STARTUPINFO
Dim pi As PROCESS_INFORMATION
Dim sa As SECURITY_ATTRIBUTES
Dim ret As Long
' Initialize structures
si.cb = Len(si)
si.dwFlags = CREATE_NO_WINDOW ' Prevents the console window from showing
sa.nLength = Len(sa)
sa.lpSecurityDescriptor = 0
sa.bInheritHandle = 0
Debug.Print sCmdLine
ret = CreateProcess(vbNullString, sCmdLine, sa, sa, 0, CREATE_NO_WINDOW, 0, vbNullString, si, pi)
If ret = 0 Then
Debug.Print "Failed to create process. Error: " & Err.LastDllError
Debug.Assert False
Else
End If
End Sub
Last edited by tmighty2; Oct 14th, 2024 at 09:16 PM.
-
Oct 14th, 2024, 09:56 PM
#94
Thread Starter
Fanatic Member
Re: Compatibility of 32-bit VB6 Applications with 64-bit SAPI
Edit: You have been really very very helpful. I inspected my manifest again and saw that while I use uiAccess=true in this application, I do not in another application of mine with about the same functionality.
I remember that I fought with it a lot as well. It seems I was indecisive whether I really needed it and kept it in that one app and removing it in the other. I guess I wanted to have a 50/50 chance to see whether it's needed.
I will remove uiAccess=true now and wait for customers complaining.
Thank you in any case. I will report back.
-
Oct 15th, 2024, 03:10 AM
#95
Re: Compatibility of 32-bit VB6 Applications with 64-bit SAPI
What I would personally try to do is make proxy executable a console application (it's just a project option in TB) and implement debug logging directly on the console and then from VB6 I would use this cExec.cls to spawn the console application hidden.
Rarely would the proxy need elevation. If it does then the VB6 driver app should be run elevated in first place (using proper manifest) so that every child process gets elevated automatically without need for declared elevation in manifest.
The best part of the cExec class above is that it prevents proxy processes from getting orphaned when the driver app crashes or is terminated from Task Manager. It groups both processes in a group so that the OS terminates all child processes when driver is exiting.
Keep in mind that lifetime of cExec instances matches lifetime of spawned processes i.e. when you set the instance to Nothing the process is terminated (process cannot outlive the cExec instance) so the usage pattern is to keep a reference in a module/global variable for the duration you need your proxy process to be accessible.
It's a different topic altogether but implementing worker processes as a console applications allows communication through console I/O i.e. driver can send commands to console and worker can asynchronously perform the task and respond to console when done. This pattern is used when handling chess engines like Stockfish from client applications.
cheers,
</wqw>
Tags for this Thread
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|