[RESOLVED] Problem with Static variable in DLL

[couttsj]

Do Static variables work in DLLs and Classes? The reason I ask is that I declared a variable as Static in a DLL that was previously working well. When I use the DLL now, it crashes the .exe.

J.A. Coutts

[Zvoni]

Well, at least for .NET it says, that Static can only be used for local variables inside procedures, so they can‘t be public and visible from outside.
Do you have any more info on the use of the variable?

[dz32]

a bit of errata, so a class level variable is stored at objptr(class) + x its data offset

a static var in a method, will use objptr(class)+staticMemOff as a pointer to a static variable memory allocation. then the actual data
is stored within that allocation. (staticMemOff will be after any local var allocs in example below it was +0x50 it will be 8 bytes after local vars anyway)

so the var values are always attached to the class instance in one way or another. If the class is still valid, not sure where the crash is coming in. Can you post a minimal example?

pcode looks like this

objptr(me) = 7E475B0
varptr(z) = 888A1E0

Function zz()
    Static z As Long
    z = z + 1
End Function

401918 Form1.zz: ; Public Function zz()  As Variant
401918    FF2E                  ZeroRetValVar
40191A    5F 08005000           FMemLdPr [arg_8+0x50]   this + 0x50 is a pointer to static var mem
40191F    8A 0000               MemLdStr [pr + 0x0]     first entry in static mem blob
401922    F5 01000000           LitI4 0x1
401927    AA                    AddI4
401928    5F 08005000           FMemLdPr [arg_8+0x50]
40192D    8F 0000               MemStI4 [pr + 0x0]
401930    FF2F 0C001000         ExitProcCbHresult copyTo:arg_C sz:0x10 

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

objptr(me) = 8AA3358
varptr(z) =  8AA338C
diff = 0x34

Dim z As Long

Function zz()
    z = z + 1
End Function

401910 Form1.zz: ; Public Function zz()  As Variant
401910    FF2E                  ZeroRetValVar
401912    08 0800               FLdPr arg_8
401915    8A 3400               MemLdStr [pr + 0x34]  ; this + 34 is actual value
401918    F5 01000000           LitI4 0x1
40191D    AA                    AddI4
40191E    08 0800               FLdPr arg_8
401921    8F 3400               MemStI4 [pr + 0x34]
401924    FF2F 0C001000         ExitProcCbHresult copyTo:arg_C sz:0x10

[couttsj]

Thank you for the responses. This problem arose when I attempted to move an encryption routine to a DLL. I included a Class because I thought that it might have a similar problem, but that is pure speculation. The key stream is declared as Static. On the first run it is empty, and the supplied key is copied to the key stream. On subsequent runs the key stream is not empty, as the key stream produced by the previous run is used.

That all worked fine when run in a module, but when I moved it to a DLL it did not. After more research, I got the impression that it could be done, but it was not easy or advisable. So I changed the library call to return the newly created key stream, and left it up to the calling program to determine the proper procedure.

J.A. Coutts

[Elroy]

I've used Static variables in ActiveX VB6 DLLs with no problem. As stated, basically all variables declared in a class (DLL or not) are specific to the particular instantiation of that class you're dealing with. If it were me, I'd start looking at your object possibly being re-instantiated, rather than something going on with the Static. If you re-instantiate, all your Static variables will be cleared.

[couttsj]

I've used Static variables in ActiveX VB6 DLLs with no problem. As stated, basically all variables declared in a class (DLL or not) are specific to the particular instantiation of that class you're dealing with. If it were me, I'd start looking at your object possibly being re-instantiated, rather than something going on with the Static. If you re-instantiate, all your Static variables will be cleared.

Don't know if it makes a difference or not, but it is not an ActiveX DLL. It is a standard DLL, which doesn't need to be registered and the entry points have to be declared.

J.A. Coutts

Addendum: I use Addon MAKEDLL from DanSoft Australia.

[dilettante]

VB6 cannot make a flat DLL. So if you engage in gymnastics to fake one all bets are off. No telling how much of the plumbing you have broken.

[dz32]

yeah I wouldnt be surprised if things are broken in that scenario. you would have to look explicitly at where that static variable memory alloc was made. Hacks are rarely perfect in such a complex system.

They are fun and all, but I wouldn’t use them for any real work or complex code.

[Elroy]

Hmm, yeah, I've never instantiated an object out of a class in a flat DLL. I do use several unregistered ActiveX DLLs though (using SxS), and they work entirely as expected.

[Elroy]

I just perused through DanSoft's GitHub entry, and I didn't see where he talks at all about creating classes and instantiating objects in these "flat" DLLs. And, if that's what you're doing, you're probably going to get completely unpredictable results (as you're getting).

Also, even static (or module level) variables in a BAS module are going to be dubious. With API declarations, I'm not clear on when (and how long) any particular library says loaded. That might be entirely up to Windows, and as soon as it's unloaded, you're going to lose all your statics.

I can see where regular API calls (with the code written in VB6) might be useful. But I wouldn't dare use all the COM machinery when doing so.

[The trick]

You should initialize a project context if you bypass the standard VB6 creation of public objects. You could create a public object then call the flat functions from your DLL. There are several variants how to create a flat dll in VB. An example, another solution.