AutoHotkey Community

Updated to version 1.06 (code in first post)
- Removed the need to include InsertInteger and ExtractInteger functions
- Output returned as Return value only
- Read buffer handling changed to handle string termination
- Added cmdstub.exe to the .zip file to support 16 bit applications

Edit: updated download (first post)

Stress test script for version 1.06

From doing a bit of testing it seems that there is an issue with trying to retrieve output from 16 bit applications. I have added cmdstub.exe to the download as a temporary solution (same method used with the .dll file) but it still seems to give an error:
Output is displayed ok if Ignore is selected... Here's the test script:

Try this :

Thanks for the workaround . It wouldn't work on Win9.x systems though...

Sure.



Unfortunately, at the moment, I only have access to Windows XP.

Thanks for the update. And thanks for changing the retrun value.

Is there a reason you removed the InsertInteger and ExtractInteger functions? Speed? Flexibility?
It seams to me that it complicates the code more then it helps reading it? I would prefer to have the functions used, since they encapsulate a special purpose/code and give it a specific name, so I do not have try to understand again the code i'm reading. And since several of my scripts already contain the InsertInteger and ExtractInteger functions it doesn't make them larger. But this is of cause personal taste.

_________________
Ciao
toralf

Version 1.06 still works as it is, but:
- without SetBatchLines -1
- with Sleep 0 instead of Sleep 20
I get an error after 640 iterations, and 20 more thereafter, with my stress scriptIt just shows that the shortened version is the same. It is a very rare scenario, that someone runs RunReturn thousands of time in rapid successions, but there could be some basic problem behind, which disappears with longer Sleep. (I know, sleep deprivation can be unhealthy .)

It does seem to simplify things and allow more flexibility. Thanks for the suggestion .
I've combined the functionality into the function for simplicity, a current lack of an include directory, many people do not regularily Include these functions (or want to have to include extras to get things working) and to have the possibility of simplifying the code a bit further (example: by filling values for multiple sections at the same time instead of having to call the function and loop multiple times for each call). At first I had thought that the code would look a lot more cryptic but honestly it doesn't look any worse than the Insert/Extract Integer function calls to me. A comment could be added at the end of each line (or on the line before if you prefer) for clarity but didn't seem necessary since these values are not adjusted throughout the code. It's probably more a matter of taste. I have a separate file that I use that lists the names, values & offsets that I refer to if I need to make a change or check a value. Do you find that the RtlFillMemory lines look any more confusing than the to the InsertInteger lines? They both contain the same info...

Laszlo, do your test results show a few characters more or less on the iterations that don't match or do you find that some have no output or some other result?

After stressing my PC a bit more and then running longer stress tests a few times, I was finding that I might get a difference of one character after around 600 - 800 times through the test (average). I wasn't able to reproduce having no output though. I'm wondering if the difference may still have to do with a bug in the way the string is stored related to the handling (or mishandling) of string termination. Does this seem like it may be the same on your system?

When doing a bit of testing with your code, I had found that the main difference in the testing was noted after replacing the IfEqual lines with If > 0 style tests and removing the use of continue. The problem seemed to disappear and then behave closer to the code I put together. I'm guessing this has to do with the timing in the read loop. My guess is that your code wouldn't have used a Sleep if the pipe didn't contain data (went back up to the start of the loop after continue - previous version I think, unless I changed it that way accidentally in testing...) and would therefore probably read smaller chunks more often. If there is an issue with dealing with string termination it would likely show up more after reading multiple times as data would be added to the result more times.

It sounds like we may have to add many more test points within the loop to try and determine where and when things are going wrong (if you haven't already). We could then compare the number of bytes in the pipe to how many we actually receive compared to how much larger the resulting string is after compared to before, does the read fail sometimes when the peek said there was data, did the process fail to start if the result was blank, if the result was blank, was there data received during that call, etc, etc...

Yes, some return values are empty. I did not check for the correctness of the result, though in version 1.06 you have a Space between pieces of output patched together. Normally, there is only one piece, and the leading Space is ignored, so there is no problem. However, if you want to be exact, AutoTrim should be turned off, and you get an extra leading Space. (The directory listing normally starts with a Space.)

I tried on 3 XP PC's, and Shimanov saw the disapearing output also on his XP machine. If you never see empty results, it must be an XP issue. But, in any case, it is timing related. With 50ms Sleep it never happened to me.

These insert extra lines of code, which makes your script slightly slower, imitating a short Sleep. However, your unchanged code (only the Sleep is removed) behaves the same on my PC.

When the error occurs, the cmdretPID process does not exist and bSize = 0, which is the only exit from the loop. I wonder, maybe sometimes it takes longer to register the process as running, or it does not start at all.

I have only observed this problem with your original code after removing the Sleep command.

On the other hand, the "robust method" in an earlier post works with, or without, the Sleep command; however, it is best to leave the Sleep command in place, to ensure the best overall performance. This is because the interprocess communication depends heavily on other system processes and the child process -- it doesn't help to starve dependencies for processor time.



This can be explained with my original conjecture:



Uncoordinated polling methods result in the observed failure.

If someone likes to experiment, I posted a shorthand version of 1.06, with variable Sleep times in the first page of the thread.

Updated code in first post to Version 1.07 beta
- Fixed string termination bug
- Fixed lack of output after multiple calls (hopefully...)

This version seems to test ok here so far... (no difference in output after multiple runs, ouput seems correct)

Hi corrupt,

Could you please explain, why you use DllCall("Sleep", Int, 10)?
Is it different then "Sleep, 10"?

I guess you set "CMcpy = a" as a temporary content, right? So that the var isn't empty. It will be overwritten anyway, right?

_________________
Ciao
toralf