Dynamically initialize SxS information?

[Elroy]

I'm wondering if there's a way to dynamically (i.e., during runtime) initialize the SxS information needed to use an ActiveX component (specifically OCX files), rather than doing it within the manifest.

I would even accept just loading the OCX and just keeping it loaded.

I do know how to load ActiveX DLLs, but I'm not sure the same approach will work with these OCX files.

------------

If this could be figured out, a class could be written to help with making programs portable. The class could extract these OCX files from resources, put them in some appropriate (publicly accessible) folder, and then initialize the SxS information ... and we'd be up and running.

IDK, just an idea.

-------------

I'll work on using the ActiveX DLL code I have (from FireHacker) to see if that approach has any possibilities.

[dilettante]

You can create an activation context and use it via the ActCtx Object or lower level calls to CreateActCtx() in Kernel32.dll, but both make use of manifests.

For example CreateActCtx() can be called during Sub Main() before loading any Forms. Load/show the main Form with vbModal. After the Forms unload control returns to Sub Main() where you can call DeactivateActCtx() then ReleaseActCtx() to clean up.

This allows any OCXs used by the Forms to work even when not registered, by using the information from the manifest.

But normally there isn't any reason to do this. Just embed the manifest and call it good.

I've only found this useful for loading plug-ins and occasionally for IDE runs where the embedded manifest doesn't take effect since the IDE is the process and it is already running.

[fafalone]

It looks like JAFAAR did this just to be able to load button images...

https://www.vbforums.com/showthread....=1#post5514521

[Episcopal]

Good Elroy, I wanted to do just that, but I don't know. I'll keep an eye on this post.

It would be nice to have DLLs and OCXs in APP.BIN\ and dynamically load them like you said....

[Arnoutdv]

It looks like JAFAAR did this just to be able to load button images...

https://www.vbforums.com/showthread....=1#post5514521

The solution is using a temporary manifest file:

Private Sub IfIdeRunApplyCC6ActCtx()
    Const WIN32_NULL = 0
    Dim CC6_MANIFEST_PATH As String
    Dim ACTCTX As ACTCTX

    CC6_MANIFEST_PATH = ThisWorkbook.Path & "\temp.manifest"
    Call CreateTempManifest(CC6_MANIFEST_PATH)
    Do: DoEvents: Loop Until Len(Dir(CC6_MANIFEST_PATH))
    If GetModuleHandle(StrPtr(vbNullString)) <> WIN32_NULL Then
        With ACTCTX
            .cbSize = LenB(ACTCTX)
            .lpSource = StrPtr(CC6_MANIFEST_PATH)
        End With
        hActCtx = CreateActCtx(ACTCTX)
        Call ActivateActCtx(hActCtx, ActCtxCookie)
        Call IsUserAnAdmin
        Call InitCommonControls
    End If
End Sub

[Elroy]

WOW, ok, lots to explore.

But normally there isn't any reason to do this. Just embed the manifest and call it good.

Yeah, I understand. And, in my mind that's fairly simple. Then, when explaining to Sam (here), I realized it's not as simple as it seemed in my head.

If I can do this "dynamic manifesting", I can write a class (possibly auto-instantiating), and then just drop it into any project, and be done with it. Yeah sure, it'll probably require a Sub Main startup, and also "touching" that class in the Sub Main to get it instantiated ... but that'd all still be much easier than explaining all the manifest details (especially to someone who's never used resources before).

Also, with this approach, I could have them drop the OCX files into their resources, and my class could unpack them, making the project quite portable (with just the EXE).

For distribution of data files, I might write a second class for unpacking and setting those out somewhere as well. We'll see.

---------------

As you can tell, I'm just really a fan of portability.

---------------

Once I start looking at these options, hopefully getting something up and running, I'll report back.

[Elroy]

Hmmm, ok, I sure hope calling ActivateActCtx doesn't override any manifest in resources. Specifically, if someone has done some DPI work in their manifest, I'd hate to override that.

The Microsoft-Learn blob isn't clear:

The lpCookie parameter is later passed to DeactivateActCtx, which verifies the pairing of calls to ActivateActCtx and DeactivateActCtx and ensures that the appropriate activation context is being deactivated. This is done because the deactivation of activation contexts must occur in the reverse order of activation.

The activation of activation contexts can be understood as pushing an activation context onto a stack of activation contexts. The activation context you activate through this function redirects any binding to DLLs, window classes, COM servers, type libraries, and mutexes for any side-by-side APIs you call.

The top item of an activation context stack is the active, default-activation context of the current thread. If a null activation context handle is pushed onto the stack, thereby activating it, the default settings in the original manifest override all activation contexts that are lower on the stack.

I also asked ChatGPT, and it says it's not overridden, but it's still not totally clear (at least to me):

Question: Does calling ActivateActCtx override any manifest that may be in an executable's resources section?

Answer: No, calling the ActivateActCtx function does not override any manifest that may be present in an executable's resources section. The ActivateActCtx function is used to activate an activation context, which is a data structure that contains information about the execution environment for a particular module. This function allows you to switch to a different activation context for the duration of a specific code block.

The manifest in an executable's resources section, typically named "manifest.xml" or embedded as an XML resource, specifies the application's dependencies, compatibility settings, and other information required for proper execution. When an executable has a manifest embedded in its resources, the operating system automatically uses that manifest to determine the application's execution environment.

The ActivateActCtx function, on the other hand, allows you to activate a different activation context explicitly. This can be useful in scenarios where you want to temporarily change the execution context, such as when loading a DLL with a specific activation context. However, it does not override the manifest specified in the resources section.

In summary, the ActivateActCtx function does not override an executable's manifest in the resources section. The manifest in the resources section is still used by the operating system to determine the application's execution environment, unless explicitly overridden using other mechanisms.

Once I get something up and running, I guess I'll have to test this. I have gotten JAFAAR's work up and running in VB6. I just now need to make it more specific to VB6, and also treat things differently depending on whether we're in the IDE vs compiled. In the IDE, I'm not going to mess with any of it (and assume we're just using our registered OCXs).

[Elroy]

FIXED BUG in BAS code below. If you grabbed it before this line appeared, re-grab it.

Ok, this is pretty cool.

I'm still very much in the "proof of concept" phase, but things do seem to be working.

Here's code I've got in a BAS module (including the Sub Main, which is used for startup):

Option Explicit
'
Private Type ACTCTX_Type ' Wide (StrPtr) version.
    cbSize As Long
    dwFlags As Long
    lpSource As Long
    wProcessorArchitecture As Integer
    wLangId As Integer
    lpAssemblyDirectory As Long
    lpResourceName As Long
    lpApplicationName As Long
    hModule As Long
End Type
'
Private Declare Function ActivateActCtx Lib "Kernel32" (ByVal hActCtx As Long, ByRef Cookie As Long) As Long
Private Declare Function CreateActCtxW Lib "Kernel32" (ByRef ACTCTX As ACTCTX_Type) As Long
Private Declare Function DeactivateActCtx Lib "Kernel32" (ByVal dwFlags As Long, ByVal Cookie As Long) As Long
Private Declare Sub ReleaseActCtx Lib "Kernel32" (ByVal hActCtx As Long)
'
Dim mhActCtx As Long
Dim miActCtxCookie As Long
'

Private Sub Main()
    CreateTempManifest
    CreateAndActivateActCtx
    Form1.Show vbModal
    RemoveCurrentActCtx
End Sub

Private Sub CreateAndActivateActCtx()
    Dim InIDE As Boolean
    Debug.Assert MakeTrue(InIDE)
    If InIDE Then Exit Sub          ' We don't mess with this if we're in the IDE.
    '
    Dim ACTCTX As ACTCTX_Type
    '
    ACTCTX.cbSize = LenB(ACTCTX)
    ACTCTX.lpSource = StrPtr(App.Path & "\temp.manifest")
    mhActCtx = CreateActCtxW(ACTCTX)
    Call ActivateActCtx(mhActCtx, miActCtxCookie)
End Sub

Private Sub RemoveCurrentActCtx()
    Const DEACTIVATE_ACTCTX_FLAG_NORMAL As Long = 0&
    '
    If miActCtxCookie Then            ' If we're in the IDE, this will always be zero.
        Call DeactivateActCtx(DEACTIVATE_ACTCTX_FLAG_NORMAL, miActCtxCookie)
        Call ReleaseActCtx(mhActCtx)
        'Call Kill(App.Path & "\temp.manifest")
    End If
End Sub

Private Sub CreateTempManifest()
    Dim sManifest As String
    sManifest = "<?xml version=""1.0"" encoding=""UTF-8"" standalone=""yes""?>" & vbCrLf & _
                "<assembly xmlns=""urn:schemas-microsoft-com:asm.v1"" manifestVersion=""1.0"">" & vbCrLf & _
                "  <assemblyIdentity type=""win32"" name=""dependencies"" version=""1.0.0.0"" />" & vbCrLf & _
                "  <file name=""msflxgrd.ocx"">" & vbCrLf & _
                "    <comClass description=""Microsoft FlexGrid Control, version 6.0 (SP6)"" clsid=""{6262D3A0-531B-11CF-91F6-C2863C385E30}"" threadingModel=""Apartment"" progid=""MSFlexGridLib.MSFlexGrid"" tlbid=""{5E9E78A0-531B-11CF-91F6-C2863C385E30}"" />" & vbCrLf & _
                "    <comClass description=""MSFlexGrid General Property Page Object""       clsid=""{6319EEA0-531B-11CF-91F6-C2863C385E30}"" />" & vbCrLf & _
                "    <comClass description=""MSFlexGrid Style Property Page Object""         clsid=""{275DBBA0-805A-11CF-91F7-C2863C385E30}"" />" & vbCrLf & _
                "  </file>" & vbCrLf & _
                "</assembly>" & vbCrLf
    '
    Dim fNr As Integer
    fNr = FreeFile()
    Open App.Path & "\temp.manifest" For Output As #fNr
        Print #fNr, , sManifest
    Close #fNr
End Sub

Private Function MakeTrue(ByRef bvar As Boolean) As Boolean
    bvar = True: MakeTrue = True
End Function

The project also has MSFlxGrd.ocx (i.e., Microsoft FlexGrid Control 6.0 (SP6)) referenced, with one copy of it on the Form1. There's no code in the Form1, so I'll let anyone who wants to try it work that out.

1. Start new Form1 project.
2. Add BAS module with above code.
3. Change project to use Sub Main.
4. Add reference to MSFlxGrd.ocx.
5. Put a MSFlxGrd.ocx on your Form1.

Now, if you run from the IDE, you're not doing anything unusual. It's only when running compiled that we're doing something nifty.

To try it compiled, you'll need to grab a copy of MSFlxGrd.ocx (typically in C:\Windows\SysWOW64) and put that copy in with your project. Interestingly, if it's not found, you get an "Out of Memory, error 7". Not sure what that's about, but basically it's telling us that the project's Form1 can't find the temp-manifest version of MSFlxGrd.ocx. If it's in the folder, everything runs fine (which is the proof of concept).

--------------

Ok, now, I'd like to make this thing even smarter, but I'll start another thread for that.

Also, when I'm done, I'll clean it all up and make a CodeBank entry.

[dilettante]

It is always risky to do this if the DLL/OCX is in a DLL search path, the EXE's path being one of them. The risk is that the runtime often silently calls the library's DLLSelfRegister() producing potentially severe chaos by registering this wonky "private" copy replacing any proper registration for a system copy that was formally (er, and formerly) installed in a system location.

This was a hack to try to help Morts do mindless deployment. It was probably the original and single biggest source of DLL Hell.

Avoid that issue by never placing dependencies "next to" the parent program. Use an application subfolder, a Common Files folder, etc. instead.

[Elroy]

Avoid that issue by never placing dependencies "next to" the parent program. Use an application subfolder, a Common Files folder, etc. instead.

Yeah, just proof of concept. I'll unwrap them into some common area once I develop that further. Actually, I suggested that above with my "put them in some appropriate (publicly accessible) folder" statement. But yeah, good advice.

[dz32]

What about the portable app makers that just bundle everything together. They probably use registry and file hooks to magically redirect things to dlls they manually loaded in memory. Never looked into the specifics but it would be a fun project.

[fafalone]

It is always risky to do this if the DLL/OCX is in a DLL search path, the EXE's path being one of them. The risk is that the runtime often silently calls the library's DLLSelfRegister() producing potentially severe chaos by registering this wonky "private" copy replacing any proper registration for a system copy that was formally (er, and formerly) installed in a system location.

This was a hack to try to help Morts do mindless deployment. It was probably the original and single biggest source of DLL Hell.

Avoid that issue by never placing dependencies "next to" the parent program. Use an application subfolder, a Common Files folder, etc. instead.

Is this only for ActiveX because it not searching for DLLs in the app path without calling SetDllDirectory has been an annoyance.

[Elroy]

What about the portable app makers that just bundle everything together. They probably use registry and file hooks to magically redirect things to dlls they manually loaded in memory. Never looked into the specifics but it would be a fun project.

dz32, my objective is to allow for the creation of an EXE that is completely portable, that also makes use of OCX files. Sure, I'll unpack these OCX files into some "temp" area, probably either %ProgramData%\MyApp\ or %LocalAppData%\MyApp\. I'm still not sure which of those would be better.

For decades, I've done this with my primary application (which has many ActiveX OCXs as well as ActiveX DLLs). However, it can get rather complex to pull all of that together, so I'm working on a way to simplify it all.

My ultimate objective is to have a self-instantiating class, to which a Sub Main can make minimal calls, and then have it all happen automagically. Sure, the developer will need to throw the OCX files into the project's resources, but that's it. I'm not sure it can be made much more simple than that.

--------

I believe I've now got all the pieces. I just need to pull it all together and do some testing. When it's all done, I'll post in the CodeBank.

[Elroy]

Ahhh, ok, I finally figured out what the difference is between %LocalAppData% and %ProgramData%. It was right in front of my nose and I didn't see it. For these purposes, I'll use %ProgramData%.

ChatGPT came to the rescue:

...

In summary, %ProgramData% is used for shared application data accessible to all users on the computer, while %LocalAppData% is used for application data specific to the current user account.

[dilettante]

I remember starting to investigate this back in 2004. When I came back to VB6 in 2006 I dug it up and started to discuss it and develop it further. I'm not sure there is much to find on it in the community before then:

http://vbcity.com/forums/t/124462.aspx

Most of the other threads are long gone now, along with a web site where I was giving away my utility as I developed it.

Then the pirates came along, cajoled and disparaged it and demanded open source code. After much effort and expense I was able to release source code.. and the pirates immediately sucked it dry and released their own - never giving any credit.

So the highly refined XCopy-packaging VB6 IDE addin that became MMM 1.0 and later will never be released to the community. It's the last thing written in VB6 that I still get paid for. Only the earlier hobbled open source beta version is out there.

Fool me once, shame on me.

[Elroy]

I remember starting to investigate this back in 2004. When I came back to VB6 in 2006 I dug it up and started to discuss it and develop it further. I'm not sure there is much to find on it in the community before then:

http://vbcity.com/forums/t/124462.aspx

Most of the other threads are long gone now, along with a web site where I was giving away my utility as I developed it.

Then the pirates came along, cajoled and disparaged it and demanded open source code. After much effort and expense I was able to release source code.. and the pirates immediately sucked it dry and released their own - never giving any credit.

So the highly refined XCopy-packaging VB6 IDE addin that became MMM 1.0 and later will never be released to the community. It's the last thing written in VB6 that I still get paid for. Only the earlier hobbled open source beta version is out there.

Fool me once, shame on me.

I've tested all the pieces. I should have something running pretty soon, maybe tomorrow.

So far, it all looks very promising.

[xxdoc123]

I remember starting to investigate this back in 2004. When I came back to VB6 in 2006 I dug it up and started to discuss it and develop it further. I'm not sure there is much to find on it in the community before then:

http://vbcity.com/forums/t/124462.aspx

Most of the other threads are long gone now, along with a web site where I was giving away my utility as I developed it.

Then the pirates came along, cajoled and disparaged it and demanded open source code. After much effort and expense I was able to release source code.. and the pirates immediately sucked it dry and released their own - never giving any credit.

So the highly refined XCopy-packaging VB6 IDE addin that became MMM 1.0 and later will never be released to the community. It's the last thing written in VB6 that I still get paid for. Only the earlier hobbled open source beta version is out there.

Fool me once, shame on me.

Thanks to the expert code, it can help a lot of people. Maybe these will go to the grave, at least everyone remembers you，Do not be sad and angry

[Elroy]

Argh, I thought I had it all working but then took it to another computer and got this error:



I'm not sure if MsFlxGrd.ocx has some DLL it also needs, or what's going on. I thought most of these OCX files had all they needed, other than core Windows DLLs.

The other computer I tried it on was a fairly up-to-date Windows 10 machine.

I'll attach my class (OcxSxS.cls) in its current state in case someone might like to help with figuring this out.

I didn't attach a complete project because it would include binaries in its resources area (which isn't allowed on these forums).

To help with testing, you'll need to setup a project as follows:

1. Download and unzip the attached OcxSxS.cls
2. Start a new Form1 project
3. Add a components reference to MSFlxGrd.ocx (IDE-->Project-->Components-->Microsoft FlexGrid Control 6.0 (SP6)
4. Add a reference to "TypeLib Information" (IDE-->Project-->References-->TypeLib Information (TlbInf32.dll)
5. Toss this OcxSxS.cls module into this new project
6. Find a copy of your MSFlxGrd.ocx file (typically in C:\Windows\SysWOW64)
7. Toss that MSFlxGrd.ocx into your project's resources under "Custom" with an ID of MSFlxGrd.ocx. It should look like the following:
   
   
   
   
8. Add a new BAS module
9. Put a Sub Main in that BAS module that looks something like the following:
   

   
   Private Sub Main()
       OcxSxS.UsingOcx True, False, "MSFlxGrd.ocx"
       Form1.Show vbModal
   End Sub
   

10. Change your project's startup to use this Sub Main
11. Throw a copy of the FlexGrid onto your Form1 (it doesn't need any info on it)
12. Compile it and run the executable

----------------

It will probably compile and execute just fine on your computer with the VB6 IDE. However, if you take it to a computer without the VB6 IDE, I believe you'll get the above error, and I don't understand why.

The temporary manifest is clearly getting activated, so I'm at a bit of a loss.

I'll try it with some other OCX and see if I get the same error.

[Joe Caverly]

I followed your instructions, copied the .EXE to Windows Sandbox, and it worked, with no errors.

On my Development system, I am running;

Windows 10 [Version 10.0.19044.2965]
BuildNumber  Caption                   CSDVersion  OSArchitecture  Version
19044        Microsoft Windows 10 Pro              64-bit          10.0.19044

System Information in Windows Sandbox says that I am running;

Microsoft Windows 10 Enterprise
10.0.19041 Build 19041

This was a fresh run of Windows Sandbox, with nothing else installed, just your VB Program.

Joe

[Elroy]

Oh WOW, I've actually got Windows Pro. I didn't think about using the sandbox.

I'll try it in the sandbox myself.

----------

It'd be GREAT if someone could compile it, put it on a thumb-drive and then try it on a computer without the VB6 IDE on it. I ran it directly off the thumb-drive and it didn't work for me. I'll keep looking at it though.

Joe, thanks a LOT for trying it.

[Joe Caverly]

I copied the .EXE to a thumb-drive,
and tried it on my wife's Windows 10 laptop,
which does not have VB6 IDE.

I ran it from the thumb-drive,
and I received the same error as you did.

Joe

[Elroy]

I copied the .EXE to a thumb-drive,
and tried it on my wife's Windows 10 laptop,
which does not have VB6 IDE.

I ran it from the thumb-drive,
and I received the same error as you did.

Joe

Hmmm, ok. Thanks very much for doing this. Before putting this in the CodeBank, I've got to figure out what's causing that and what the limits are. I'll continue working on it.

[Joe Caverly]

When I run the compiled .EXE on my VB6 IDE system,
using Process Explorer, I see


That is, 2 x C:\Windows\SysWOW64\msflxgrd.ocx
and 1 x C:\ProgramData\Project1_OCX\MSFlxGrd.ocx

If I un-register the C:\Windows\SysWOW64\msflxgrd.ocx thus;

RegSvr32 /u MSFlxGrd.ocx

...and run the compiled .EXE, I see


As my knowledge of VB6 is not as advanced as others on this forum,
I was just wondering why it shows 2 x MsFlxGrd.ocx for DLL,
and 1 x MSFlxGrd.ocx for File.

Joe

[Elroy]

Joe, again, thanks for exploring this.

And your question is a good one. I've got no idea why it's showing three references. It's only got a single reference to the grid control on the Form1.

p.s. Don't forget to re-register it in SysWOW64, or it won't work correctly in your IDE.

[Dragokas]

... with this approach, I could have them drop the OCX files into their resources, and my class could unpack them, making the project quite portable (with just the EXE).

What is the reason in dynamic SxS loading? - My application is easily loading with reg-free manifest and missing dependency without errors while you load from the Main() or load form having no reference to the missing component.
Is that not true for a specific OCX?

I had experience only with VBCCR, and yeah, I had issues with manifest distributed within original project until I re-created manifest using UMMM. That solved everything. Program is launched, checks for ocx, tells to user if OCX is missing (my messagebox), at that moment you can put OCX file (or unpack from resources), and app will successfully load the form which require that component.