Page 2 of 2 FirstFirst 12
Results 41 to 43 of 43

Thread: Krools Common Controls - Documentation and an Update/Compile Utility

  1. #41
    Member Dragokas's Avatar
    Join Date
    Aug 2015
    Location
    Ukraine
    Posts
    661

    Re: Krools Common Controls - Documentation and an Update/Compile Utility

    Looks promisingly. Looking forward to test your software =)
    BTW, I'd suggest to overlook a helper code for missing Wow64RevertWow64FsRedirection, because there are some scenarios, e.g. in ShellW, where it is not paired due to using "goto" statements. It's also good practice to store "OldValue" parameter globally to prevent "out of sync" even if above case happened.
    The same actual for all other functions like "File Exist" where I don't see redirector functions at all, which surely have to be implemented in tools like "file manager".

    Quote Originally Posted by MountainMan View Post
    I didn't know you could run VB6.EXE, even the commandline version, without elevating.
    This is a default behaviour after installation. Perhaps, you patched exe file via manifest, or set Admin mark in exe's or shortcut's properties, that's why it is always ask you for elevation.
    I don't insist that it should be "must have" feature, since I can always create a special shortcut to bypass UAC, but ability to compile as non-elevated where possible would be good manner. Also, the user should understand he can manually start your tool elevated if he knows his project require higher privileges in order to compile.
    Last edited by Dragokas; Jul 27th, 2021 at 05:40 AM.
    Malware analyst, VirusNet developer, HiJackThis Fork author || my CodeBank works

  2. #42

    Thread Starter
    Addicted Member
    Join Date
    Feb 2015
    Location
    Colorado USA
    Posts
    189

    Re: Krools Common Controls - Documentation and an Update/Compile Utility

    When I installed VB6 I set my system to elevate VB6 each time it was run. I did that because everybody I had read (some here) say that because VB6 writes into a section of the registry that isn't accessible any more without elevation. What cases have you found it acceptable to run VB6.EXE without elevation?

    Tell me more about helper code. When I use Goto I try to ensure that I don't have any orphaned or "out of sync" variables.If you see any in my code please let me know.

  3. #43
    Member Dragokas's Avatar
    Join Date
    Aug 2015
    Location
    Ukraine
    Posts
    661

    Re: Krools Common Controls - Documentation and an Update/Compile Utility

    Quote Originally Posted by MountainMan View Post
    When I installed VB6 I set my system to elevate VB6 each time it was run. I did that because everybody I had read (some here) say that because VB6 writes into a section of the registry that isn't accessible any more without elevation. What cases have you found it acceptable to run VB6.EXE without elevation?
    I'll split answer in 2 use cases:
    1) Run IDE.
    Personally, I see the only reason when one needs to run IDE non-elevated - to be able debug code in the same (or very close) environment as it will be run further by user to have the opportunity to catch all those possible "access denied" errors and so. Or when you, e.g., develop an application which by design should always be run with restricted permissions to prevent cases, e.g., when you think some function should work normally both as admin / and non-admin, but it is not true (like the above case with SHFileOperation).

    In all other "design" cases, VB6 IDE is really suffered from those access denied errors when one try to add new, not yet registered components / references and so on, which write themselves to HKLM and thus required admin access. Such a way, yes, it's much convenient to work always as evelated.

    2) Compile.
    It's also convenient to compile project as elevated every time.
    But it's not always convenient for end user. Like, if one wants to integrate OCX2StdExe into another builder script which by design is not intended to run as admin.
    Surely, it's up to you, do a little change to support non-elevated compilation, or stay as is. But if second, than a logical question: why not force "requireAdministrator" instantly in the manifest of your tool...

    Quote Originally Posted by MountainMan View Post
    Tell me more about helper code. When I use Goto I try to ensure that I don't have any orphaned or "out of sync" variables.If you see any in my code please let me know.
    Well, look ShellW function.
    Code:
    j = Wow64DisableWow64FsRedirection(DisableWOW)
    Firstly, I suggest to declare DisableWOW globally. So, the system can re-use those value when needed (when you'll have more such use cases in your code, of course).
    Even, if Wow64RevertWow64FsRedirection pair will be lost, you will not lose tracking of DisableWOW value, used by system for special purposes to sync the redirector state.

    Second, you have a lot of labels for "goto", such as Leaving/DoSee0/DoSEE1. E.g., see this part:
    Code:
                ShellProcInfo.hProcess = 0
                GoTo Leaving
                End If
             AsAdmin = AdminYes
             GoTo RunElevated ' failed to run un-elevated & AsAdmin is AdminOnlyIfNeeded
          Else
             i = Err.LastDllError
             End If
          End If
       End If
    '#If (Win64 = 0) Then
    ' If hModule <> 0 Then FreeLibrary hModule
    '#End If
    If IsWOW64 Then
       're-enable redirection
       j = Wow64RevertWow64FsRedirection(DisableWOW)
       If j = 0 Then
    If those goto executed, it jump over Wow64RevertWow64FsRedirection, so the redirector remains disabled.
    I didn't learn all the code, just a quick look.

    Another potential lose of pair could happen if code trapped runtime error for some reason.

    And the last, to make code (faster?/more stable): file system redirector affects only C:\Windows\System32 (with 2 exclusions), so no need to manipulate it for other paths. Simple way is to check just for "C:\Windows"). I'm using such helper routine.
    Second reason is such Microsoft does not suggest to disable it for a long time. So, it's very important to track this moment carefully. Some functions from my practice are working incorrectly with redirector turned off (example: WinVerifyTrust).
    Malware analyst, VirusNet developer, HiJackThis Fork author || my CodeBank works

Page 2 of 2 FirstFirst 12

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
  •  



Click Here to Expand Forum to Full Width