New _Singleton() need opinion

[Terenz]

We need @Jos @jpm or any developer here because the result don't have any sense. Summarize, for us is implicit that every point will work:

1) Using DllCall passing direcly "Kernel32.dll" with default security descriptor for you NOT WORK

2) Using DllCall + DllOpen with default security descriptor for you WORK

3) Using DllCall passing direcly "Kernel32.dll" with a custom security descriptor for "Everybody" for you WORK ( post #7 )

The question for the dev is simple:

Why, with default security descriptor, FAIL passing the DLL directly for @therks and NOT FAIL if he open before with DllOpen? Where is the problem here since for us work in both way? From the DllCall page:

If a dll filename is given then the DLL is automatically loaded and then closed at the end of the call

So what is different between DllCall("Kernel32.dll") and DllCall($hDLL) and why on his machine there is this problem? Since is implicit the ERROR_MOD_NOT_FOUND does mean it can't find the DLL or the module but at the same time with a custom security descriptor DllCall without DllOpen will find?

Edited October 28, 2016 by Terenz

[Danyfirex]

Hello. @Terenz I think developers will not be able to answer your question. It's hard to deduct the issue without have access to the machine to do a deep analysis.

I think DllOpen and DllCall work same way. The only diference is that using DllOpen you can avoid using LoadLibraryW each time you  Call the function.

 

Saludos

[Terenz]

Hello @Danyfirex,

We can just speculate, without see the autoit source code, that DllCall with filename use the same technique of DllOpen. If was the same on the machine of @therks this:

DllCall("kernel32.dll")

Need to be equal to this:

$hDLL = DllOpen("kernel32.dll")
DllCall($hDLL)
DllClose($hDLL)

But instead give two different result, the first not work and the second one yes. Rembember, this problem is here from 11 years so is cross-platform with OS, architecture and hardware. I don't know if is imputable to autoit but only @Jos i'm sure can find the answer. The devs can do all the test they want since we have in this thread one of the guy with the problem, or we will wait another x years to resolve definitively?

Edited October 28, 2016 by Terenz

[Danyfirex]

I didn't  speculate. I said how it really works.

 

Saludos

[Terenz]

How can you know? The last autoit source avaiable don't have DllCall:

NOTE: For obvious reasons this archive doesn't contain all the new features in the current version of AutoIt.  The code for these features may be made vailable at a later date.

Excluded features are:
- DllCall

So is only a hypothesis or you have see the actual source?

Edited October 28, 2016 by Terenz

[Danyfirex]

I don't need to see source code to know how it works. 

No. It's not a   hypothesis.

Saludos

[Terenz]

You use an API-COM Monitor? But if there is someware a bug in the code you'll never knows, more you don't know if on his machine the LoadLibraryW called by DllCall is successfull or not, and if not why since there isn't any advanced debugging option included. Anyway if you have the knowldge try to help or suggest what to do for resolve the problem...

[Danyfirex]

For that reason I said Dev would need  to have access to the machine to do a deep analysis about return values. or be able to simlute the issue in his own machine.

 

Probably @therks could try another kernel(and others) API calls. using both method and check if module is load correctly because issue seem to be while using LoadLibrary(internally).

 

Saludos

 

 

 

 

 

[Jos]

1 hour ago, Danyfirex said:

The only diference is that using DllOpen you can avoid using LoadLibraryW each time you  Call

Nearly correct, they both use LoadLibrary() 

Jos

[Terenz]

@Jos

LoadLibrary is from Kernel32.dll so pratically call itselft?

DllCall("kernel32.dll", "handle", "LoadLibraryW", "wstr", "kernel32.dll")

Since you are here, i'm very curious what do you suggest or what @therks can try since any kernel object fail on that machine without DllOpen and why not fail with a custom security decription instead of the default one...on our machine everything work fine. This isn't a single case, at least 7 people here have it now or in the past the same issue but i'm sure there are more, considering the autoit forum in other languages.

Edited October 28, 2016 by Terenz

[Jos]

No idea and not really the time available to start digging into it.

Jos

[Terenz]

Ok, i'll hope you or other devs can check it out where is the problem.

[Danyfirex]

I think this is not an issue of AutoIt Internal design. It's more an OS issue. So I do not think it's something that a developer can know without an internal analysis. 

Probably you can use some debug tools to get the real issue. 

 

Saludos

[Terenz]

@Danyfirex instead i'll think the opposite. There is a easy way to enstablish. A compiled C++ with the same example we have, a kernel object like mutex or semaphore with same errore checking. If that will work is absolutely an autoit bug, instead we can archive this like OS problem but i'm not so sure about that. Who want to make this binary with C++ or any language except autoit, using the API CreateMutexW or CreateSemaphoreW?

Edited October 28, 2016 by Terenz

[Danyfirex]

If I got free time. I'll do.

 

Saludos