Multithread...

[arcker]

recently, i've stopped with autoit, because of his singlethread conception

i know i'm really boring, and that's it's difficult, but when you want to make multiple loops, autoit is not enough powerful

so, my question is: will autoit manage to multithread in the future ? because i love it, and i hate .NET

long life to autoit, our first script langage in our firm now...

[Thatsgreat2345]

well you can multithread just by making a bunch of .a3x's

[w0uter]

if you can code in hex you could create a bit of code using dllstruct and then createthread on that dllstruct.

[neogia]

if you can code in hex you could create a bit of code using dllstruct and then createthread on that dllstruct.

Can you give a small example of this? Say, a msgbox stating that "w0uter rocks my world with his h4x" ? I would be superbly interested in this to no end.

[ptrex]

@Arcker

Why not use this ?

MultiThreaded

[arcker]

mmmm didn't aware...

erf, some work to do again, i must learn... snif

anyway,thx for the solution

i just want to say why it cannot be multithreaded

i've created in irc client, but without tcpevent or another, it's really difficult, so i've stopped

but, school is finished soon, i will return in my firm, because they have employed me to male some scripts

in autoit and some programs... they have adopted it, i'm really proud, for you at first, because you merit this

autoit power

i will buy a t-shirt of it, and a mug lool

[w0uter]

Can you give a small example of this? Say, a msgbox stating that "w0uter rocks my world with his h4x" ? I would be superbly interested in this to no end.

Never noticed that post till it got bumped now, better late then never.

expandcollapse popup

Func _CreateStruct($s_Str)
    Local $v_Struct = DllStructCreate('char[' & StringLen($s_Str)+1 & ']')
    DllStructSetData($v_Struct, 1, $s_Str)
    return $v_Struct
EndFunc

$v_Title = _CreateStruct("I Am A Box.")
$v_Text = _CreateStruct("w0uter rocks my world with his h4x.")
$v_Ret = DllStructCreate('byte')

$v_ASM = DllStructCreate( _
    'byte;int;' _   ;01~02 00401000 >    68 00000000                 PUSH 0                                                  ; /Style = MB_OK|MB_APPLMODAL
&   'byte;int;' _   ;03~04 00401005   .  68 07204000                 PUSH Protect.00402007                                   ; |Title = "lpCaption"
&   'byte;int;' _   ;05~06 0040100A   .  68 00204000                 PUSH Protect.00402000                                   ; |Text = "lpText"
&   'byte;int;' _   ;07~08 0040100F      68 00000000                 PUSH 0                                                  ; |hwnd = 0
&   'byte;int;' _   ;09~10 00444448 >    B8 EA04D577                 MOV EAX,USER32.MessageBoxA
&   'byte;byte;' _  ;11~12 0044444D      FFD0                        CALL NEAR EAX
&   'byte;int;' _   ;13~14 00401019      A2 44332211                 MOV BYTE PTR DS:[11223344],AL
&   'byte' _        ;15~15 0040101E      C3                          RETN
)

DllStructSetData($v_ASM, 01, 0x68)
DllStructSetData($v_ASM, 02, 4)

DllStructSetData($v_ASM, 03, 0x68)
DllStructSetData($v_ASM, 04, DllStructGetPtr($v_Title))

DllStructSetData($v_ASM, 05, 0x68)
DllStructSetData($v_ASM, 06, DllStructGetPtr($v_Text))

DllStructSetData($v_ASM, 07, 0x68)
DllStructSetData($v_ASM, 08, 0)

DllStructSetData($v_ASM, 09, 0xB8)

;~ HMODULE WINAPI LoadLibrary(
;~   LPCTSTR lpFileName
;~ );

$v_Lib = DllCall('kernel32.dll', 'int', 'LoadLibrary', 'str', 'user32.dll')

;~ FARPROC WINAPI GetProcAddress(
;~   HMODULE hModule,
;~   LPCSTR lpProcName
;~ );

$v_Msg = DllCall('kernel32.dll', 'int', 'GetProcAddress', 'int', $v_Lib[0], 'str', "MessageBoxA")

DllStructSetData($v_ASM, 10, $v_Msg[0])

;~ BOOL WINAPI FreeLibrary(
;~   HMODULE hModule
;~ );

DllCall('kernel32.dll', 'int', 'FreeLibrary', 'int', $v_Lib[0])

DllStructSetData($v_ASM, 11, 0xFF)
DllStructSetData($v_ASM, 12, 0xD0)

DllStructSetData($v_ASM, 13, 0xA2)
DllStructSetData($v_ASM, 14, DllStructGetPtr($v_Ret, 1))

DllStructSetData($v_ASM, 15, 0xC3)

;-----------------------------------------------------------------------------------------------------------------------------------------

;~ HANDLE WINAPI CreateThread(
;~   LPSECURITY_ATTRIBUTES lpThreadAttributes,
;~   SIZE_T dwStackSize,
;~   LPTHREAD_START_ROUTINE lpStartAddress,
;~   LPVOID lpParameter,
;~   DWORD dwCreationFlags,
;~   LPDWORD lpThreadId
;~ );

;-----------------------------------------------------------------------------------------------------------------------------------------

DllCall('kernel32.dll', 'int', 'CreateThread', 'int', 0, 'int', 0, 'int', DllStructGetPtr($v_ASM), 'int', 0, 'int', 0, 'int', 0)

$i = 0

While DllStructGetData($v_Ret, 1) = 0
    $i += 1
    ToolTip($i)
WEnd

ToolTip('')

MsgBox(0, 'End', 'The Msgbox return was: ' & DllStructGetData($v_Ret, 1))

Edited July 18, 2006 by w0uter

[SmOke_N]

w0uter, simply Great!! This is what people have been looking for for a while, I found no need in the past for it, but have seen how much easier my applications have become having options like this and Multi Processing! But a new thread all together.... Wonderful!

Thanks for sharing!

[jvanegmond]

Multithreading basically is running multiple scripts/programs that have acces to the same variables, normally by sharing memory. But if you share Registry keys, it actually is multithreading..

The need for multithreading is only created when one is unabled to code the same script without the need of multithreading.

Edit: Too soft.

Edited July 18, 2006 by Manadar

[w0uter]

Multithreading basically is running multiple scripts/programs that have acces to the same variables, normally by sharing memory. But if you share Registry keys, it actually is multithreading..

The need for multithreading is only created when one is unabled to code the same script without the need of multithreading.

Edit: Too soft.

Go and read what a thread actually is please.

[SmOke_N]

Multithreading basically is running multiple scripts/programs that have acces to the same variables, normally by sharing memory. But if you share Registry keys, it actually is multithreading..

The need for multithreading is only created when one is unabled to code the same script without the need of multithreading.

Edit: Too soft.

I think you have a misunderstanding between "Needed" and "Desired" effect... Or in your coding history, have never ran into a situation where it would be preferable to have such an option.

[Valik]

This still isn't very useful outside of proof of concept, though. Okay, yes, w0uter created a thread. That's easy enough to do for somebody who knows assembly and understands how to write the opcodes to memory. The problem is, how are you going to get the second thread to do anything? It can't share variables with AutoIt. You can't execute AutoIt code in the separate thread. In fact, the only thing you can do is write opcodes to memory and have them executed so you're essentially just writing assembly.

Most multi-threaded applications are multi-threaded because writing a single-threaded version would be vastly more difficult because of the amount of code required to make two separate tasks run in parallel. If you have to write all your thread routines in assembly, you might as well just write your own parallelization library in AutoIt. For most people, the difficulty is about the same.

So while it's true that this code demonstrates how to create a thread, it's really not as great as it seems. It is not the multi-threaded solution people want it to be. SmOke_N, I'm a little disappointed in your reaction. I know you've seen me state that multi-threading in AutoIt isn't possible, so why do you think such a simple (And what w0uter is doing is simple when you get right down to it) piece of code would be that magical solution?

[SmOke_N]

SmOke_N, I'm a little disappointed in your reaction. I know you've seen me state that multi-threading in AutoIt isn't possible, so why do you think such a simple (And what w0uter is doing is simple when you get right down to it) piece of code would be that magical solution?

Ouch, I've had a few tonight... 7 - 0 in my match ... Can I get a hooo hah Tuesday!! (Dominos Pizza Joke), so lets see if I can type literate or not.

No need to be dissapointed in me, I respect and back up 99.9% of what you say. But even you wouldn't be where you are today, if you didn't step "outside" the box every once and a while... For that, w0uter has my appreciation, and respect.

[w0uter]

It can't share variables with AutoIt.

You do realise i wrote the return of the MessageBoxA call into a dllstruct ?

Ofcourse, its a bit hack'ish, but its possible.

It is not the multi-threaded solution people want it to be.

It doesnt have to be.

It just an example how to create a thread and have simple interaction with it.

multi-threading in AutoIt isn't possible

You should really word that diffently since i just proved that was wrong, it should be more like:

"multi-threading AutoIt's script parser isn't possible without craches"

or something along those lines.

Edited July 19, 2006 by w0uter

[Valik]

w0uter, I won't change what I said but I will make the distinction clearer. I don't want to say "native" threading but that's essentially what I mean. I don't consider what you are doing "multi-threading in AutoIt". While clearly you do have multiple threads running, as I said, it's not really useful to most people. It requires experience in assembly language at best since that's pretty much what is being written. Since that is the case, why not write the thread procedure in another language and call it from AutoIt? Also, you can't share variables very well. They have to be marshaled through a C-type which means not every type is supported.

So it's multi-threading on a technical level, but not really on a practical level. But then if we want to get technical about it, AutoIt was already multi-threaded because InetGet() always downloads in a separate thread. I know that you understand these distinctions. The code itself isn't without merit. At least it shows something people don't think is possible. It's just not the solution people think they want it to be.

[w0uter]

I can live with that awnser

Also i got the idee from the threaded timed msgbox in autoit

[jvanegmond]

I think you have a misunderstanding between "Needed" and "Desired" effect... Or in your coding history, have never ran into a situation where it would be preferable to have such an option.

I've found many instances where it would be easier to have a multihread option, but I have also always found a work-around for it, and seeing all the effort people are putting into this, without really coming up with a good solution: Just leave it as is, or switch language.

[SmOke_N]

I've found many instances where it would be easier to have a multihread option, but I have also always found a work-around for it, and seeing all the effort people are putting into this, without really coming up with a good solution: Just leave it as is, or switch language.

At least some are making an effort to "try" even if it doesn't work or get implimented as hoped... besides, wasn't really anything made better without an effort (Hmmm, just thought of the support forum... guess I'm wrong there ). Edited July 21, 2006 by SmOke_N

[arcker]

huh this post is here now ^^ proud of that

so i don't want a "native" multithread but some wqork-around to do it

one example ?

i want to ping several machines while i can continue to use my script

i know that i can use others script that i execute, but it's the same, because i must wait the script to end

i think it could be good to have an option for it, not really a multithread, but something like that

i really don't know about it, so i can say anything, but i've learn more with your posts

thanx for that

[nfwu]

i can use others script that i execute, but it's the same, because i must wait the script to end

Use the Run function instead of the RunWait function.

#)