dll is not working in windows10

[senatin]

I have a 32bit dll that works fine in windows7 but when I use 64bit dll in windows10 It didnt work with my autoitscript.
I also tried to unblock dll from its properties/attributes still no luck.

[JLogan3o13]

@senatin the problem is on line 13...

Perhaps you could post your script rather than expecting us to guess.

 

[senatin]

#RequireAdmin

Local $hDLL = DllOpen("wcx64.dll")

HotkeySet ( "-", "start")
HotkeySet ( "=", "ext")

While 1
    sleep(100)
WEnd

Func start()
    DllCall($hDLL, "none", "frwd_txt", "String", "Hi im looking for a trustworthy client. If you are interested to trade with me, please send me first a scanned copy of any of your valid ID")
EndFunc
 
Func ext()
    DllClose($hDLL)
    Exit
EndFunc

 

[RTFC]

Does @autoitX64 return true? Try adding directive:

#AutoIt3Wrapper_UseX64=Y

 

[senatin]

When I run The script WIth  

#AutoIt3Wrapper_UseX64=Y

the console send me this msg :

! your script requires Admin rights while SciTE is running at normal level.
! This means no Console output from the script will be displayed and SciTE will show the script as ended right away.

in Red txt

 

[Jos]

That message is unrelated to 

#AutoIt3Wrapper_UseX64=Y

but caused by 

#RequireAdmin

and your SciTE editor not running in elevated mode.

Jos

[senatin]

I deleted #requireAdmin

but with #AutoIt3Wrapper_UseX64=Y it give me error when I use wc64.dll. Instead, when I try wc32.dll which is (64bitwindows 32bitexe ) dll dont give me error but still the script not working as it should be

 

I dont understand if windows10 is 64bit windows 64bitexe or 64bitwindows 32bitexe.
I keep on trying both dll.
I believe its 64.64bit, How can I identify it

Edited October 13, 2017 by senatin

[senatin]

56 minutes ago, RTFC said:

Does @autoitX64 return true? Try adding directive:

#AutoIt3Wrapper_UseX64=Y

 

What do you mean by return true?
I tried to use autoit_X64 with #autoIt3Wrapper_UseX64=Y and dll is giving me error.

[BrewManNH]

Run the script from SciTE and show us the entire output from scite to see what is happening.

[RTFC]

58 minutes ago, senatin said:

What do you mean by return true?

From the help file:

Quote

@AutoItX64 Returns 1 if the script is running under the native x64 version of AutoIt.

True = 1, False = 0. So using something like:

Consolewrite("x64 = " & @AutoItX64 & @CRLF)

would inform you whether you're running in x64, which is required if you're calling a 64-bit dll. But from your comments, I gather you're calling a 32-bit dll from a regular script running in 32-bit (the default, unless you've explicitly set it up otherwise).

1 hour ago, senatin said:

I believe its 64.64bit, How can I identify it

Find "This PC" in your file manager, right-click, select "Properties", then look under "System Type". To run AutoIt scripts in x64, you need a 64bit processor, a 64 bit operating system, and that directive I mentioned in my previous post. If you're just calling the 32-bit dll, processor and OS can be either 32 or 64 bit.

Edited October 13, 2017 by RTFC

[senatin]

3 hours ago, BrewManNH said:

Run the script from SciTE and show us the entire output from scite to see what is happening.

 

I will post later the output because my friend already gonehome with his laptop. We will be fixing it again later

 

2 hours ago, RTFC said:

From the help file:

True = 1, False = 0. So using something like:

Consolewrite("x64 = " & @AutoItX64 & @CRLF)

would inform you whether you're running in x64, which is required if you're calling a 64-bit dll. But from your comments, I gather you're calling a 32-bit dll from a regular script running in 32-bit (the default, unless you've explicitly set it up otherwise).

Find "This PC" in your file manager, right-click, select "Properties", then look under "System Type". To run AutoIt scripts in x64, you need a 64bit processor, a 64 bit operating system, and that directive I mentioned in my previous post. If you're just calling the 32-bit dll, processor and OS can be either 32 or 64 bit.

I will definitely try this one later. but as I recall his system was 64bit processor, 64 bit OS. 
I will post more later about the output.

hmm I Think I better make a script that Identify the processor and OS of windows so the script itself will address which dll is compatible. I think I will start with that consolewrite script of yours.

 

#AutoIt3Wrapper_UseX64=Y

Local $hDLL
If @AutoItX64 Then
   $hDLL = DllOpen("wcx64.dll")
Else
   $hDLL = DllOpen("wc32.dll")
EndIf

HotkeySet ( "-", "start")
HotkeySet ( "=", "ext")

While 1
    sleep(100)
WEnd

Func start()
    DllCall($hDLL, "none", "frwd_str", "String", "Hi im looking for a trustworthy client. If you are interested to trade with me, please send me first a scanned copy of any of your valid ID")
EndFunc
 
Func ext()
    DllClose($hDLL)
    Exit
EndFunc

This work right?

Edited October 13, 2017 by senatin

[RTFC]

19 minutes ago, senatin said:

This work right?

Dunno, my ESP is a little off today. Selecting the appropriate version of the dll makes sense (although you're usually okay calling a 32-bit dll in a 64-bit environment (but NOT the other way around!)). However, the call itself may not work. Does that dll actually have a function called "frwd_str"? (You can check with free utilities such as dependency walker for example) Is the parameter type really "STR", i.e., an ANSII string, or maybe it expects WSTR (Unicode) instead, or maybe it expects a pointer to a buffer variable where your string resides? If you have access to the dll source or working code examples with source, you can find out. If the exact same script you posted runs on W7, then this should be okay.

But what you should definitely add is error-checking immediately after DllCall, i.e, upon return, does @error perhaps contain:

Quote

@error:

1 = unable to use the DLL file, 2 = unknown "return type", 3 = "function" not found in the DLL file, 4 = bad number of parameters, 5 = bad parameter.

 

[senatin]

Yah it works in W7 with the 32bit dll but 64bit was said to be the same so I expect it has the function aswell.
I'll try the @error I think thats what I needed. Though I cant still post the error today my friend still not coming.

 

my friend still not coming
hope I can continue this combo

Edited October 16, 2017 by senatin

[senatin]

On 10/14/2017 at 4:22 AM, RTFC said:

Dunno, my ESP is a little off today. Selecting the appropriate version of the dll makes sense (although you're usually okay calling a 32-bit dll in a 64-bit environment (but NOT the other way around!)). However, the call itself may not work. Does that dll actually have a function called "frwd_str"? (You can check with free utilities such as dependency walker for example) Is the parameter type really "STR", i.e., an ANSII string, or maybe it expects WSTR (Unicode) instead, or maybe it expects a pointer to a buffer variable where your string resides? If you have access to the dll source or working code examples with source, you can find out. If the exact same script you posted runs on W7, then this should be okay.

But what you should definitely add is error-checking immediately after DllCall, i.e, upon return, does @error perhaps contain:

 

I tried @error unfortunately it give 1 which means unable to use dll file

But if i use dllopen it return me 0

Is the dll still being blocked?

Edited October 17, 2017 by senatin

[senatin]

heres what I got

Using this script

#AutoIt3Wrapper_UseX64=Y

Local $hDLL
If @AutoItX64 Then
   $hDLL = DllOpen("wcx64.dll")
   ConsoleWrite("using 64bit : " & $hDLL & " @error = " & @error & @CRLF)
Else
   $hDLL = DllOpen("wcx32.dll")
   ConsoleWrite("using 32bit : " &$hDLL & " @error = " & @error & @CRLF)
EndIf

HotkeySet ( "-", "start")
HotkeySet ( "=", "ext")

While 1
    sleep(100)
WEnd

Func start()
    ConsoleWrite("execute dll" & @CRLF)
    DllCall($hDLL, "none", "frwd_str", "String", "Hi im looking for a trustworthy client. If you are interested to trade with me, please send me first a scanned copy of any of your valid ID")
    ConsoleWrite (@error & @CRLF)
EndFunc

Func ext()
    DllClose($hDLL)
    ConsoleWrite("dll closed. @error = "&@error)
    Exit
EndFunc

Dll Error appeared  It says  

"Please run this program as an administrator"

and if I add #RequireAdmin

"Drive Startup error"

with this in console

"! Your script requires Admin rights while SciTE is running at normal level.
! This means no Console output from the script will be displayed and SciTE will show the script as ended right away."

Edited October 17, 2017 by senatin

[Danyfirex]

Hello. 

 

DllCall does not support String data type in the parameter field. It should be wstr or str.

If you want to be the console output while you're using #RequireAdmin You need to run SciTE with admin Right. right click over ScITE icon  Run as Admin...

Also make sure If dll use 'stdcall'  or 'cdecl' calling method...

 

Saludos

 

[Jos]

5 hours ago, senatin said:

with this in console

"! Your script requires Admin rights while SciTE is running at normal level.
! This means no Console output from the script will be displayed and SciTE will show the script as ended right away."

Thought I already made that clear several days ago! ... guess not. 

On 13-10-2017 at 5:44 PM, Jos said:

That message is unrelated to 

#AutoIt3Wrapper_UseX64=Y

but caused by 

#RequireAdmin

and your SciTE editor not running in elevated mode.

Jos

Jos

[senatin]

Yah I im clear with it but When I dont put The #RequireAdmin the dll give me error of  "Please run this program as an administrator"
So I put it back and I get new error which is  "Drive Startup error"

[Danyfirex]

@Jos lol I know...

 

Saludos

[senatin]

@Danyfirex I dont get what you mean by stdcall or cdecl. How Can I know if my dll uses which is which