StdIn / StdOut in relation to temporary file creation

[KnutJ]

Hello Community,

i am new here, but actively generating AutoIt-Sources for about a year.

In the past 25+ years i have been programming in many different languages on different platforms.

i have been searching through the forums for about half a year till now without even being registered.

It might be that i have been looking in the wrong places, using the wrong keywords or something alike, but i cannot find a clear and precise answer to the following question which emerged 2 or three times as a sidenote.

i noticed a strange behaviour when using StdinWrite:

  it creates Files in %TEMP% which follow the filename-pattern scs[n].tmp (ranging from 1-199 as far as i can see)

Windows Server 2003 32bit

AutoIt3Wrapper 2.1.2.9

aut2exe 3.3.8.1

Maybe i am trying it the wrong way, therefore i include the Source and the sample-content of the .tmp-File

The Source is tightly based upon the sample-source for StdinWrite from the Helpfile

Content of StdWrite-Test.au3

; Demonstrates the use of StdinWrite()
#include <Constants.au3>

Const $SearchAddress = "F000:0000"

Local $DebugCommands = "d " & $SearchAddress & @CRLF & "q" & @CRLF

MsgBox(0, "Debug", $DebugCommands)

Local $foo = Run(@ComSpec & " /c " & 'debug.exe', "", @SW_SHOW, 3)
; Write string to be sorted to child debug.exe's STDIN
StdinWrite($foo, $DebugCommands)

; Calling with no 2nd arg closes stream
StdinWrite($foo)

; Read from child's STDOUT and show
Local $data
While True
    $data &= StdoutRead($foo)
    If @error Then ExitLoop
    Sleep(25)
WEnd
MsgBox(0, "Debug", $data)

Content of (in this case) scs27.tmp

d F000:0000
q

Any help is appreciated.

Hopefully the solution shows a way by which the scs*.tmp Files are not generated during the process. Sure i can delete them directly after StdoutRead is finished. But I would really appreciate no file-output at all.

Greetings

Knut J.

P.S.: The real source is much larger and more complex, but this snippet reacts exactly like the part in the big source, so i just posted the small extract / close to the reference-use to keep the number of code-lines as small as possible.

P.P.S.: If there is a more elegant solution to read memory in that region (BIOS-Content) i would also like to test the different approach if it doesn't generate output-files.

[KnutJ]

Is this a question which is not going to be answered due to restrictions, or is it too deep inside of autoit, and noone wants to give it a try?

[DatMCEyeBall]

If it was against the forum rules than it would've been locked/removed, believe me, those moderators are fast. So that means that that someone that can fix your problem hasn't shown up yet - keep waiting, some questions are only answered after a couple of days.

[KnutJ]

...Meanwhile in a different dimension, i had the possibility to test my example on a Windows-XP PC

it generates the same (using a different numer in the filename) content in C:WindowsTemp

i do not understand how this effect can be in the autoit-core without ever being noticed.

when this function is used thorougly... it will fill the temp folder in a short amount of time with hundreds of SCS(n-nnn).tmp files by no means.

i have no idea what happens when the file already exists upon creating the new instance, but is (at that time) write protected or accessed by an older task. will my whole script fail? there is no documented way to check if the .tmp file was created and everything is doing fine.

The ReadStdOut works without .tmp file, so why does the WriteStdIn Function use one? (and doesn't clean up afterwards)

Regards

Knut J.

[JFX]

P.P.S.: If there is a more elegant solution to read memory in that region (BIOS-Content) i would also like to test the different approach if it doesn't generate output-files.

On Windows XP and earlier you can open devicephysicalmemory to read the memory.

With Windows 2003 there is the GetSystemFirmwareTable API to get the BIOS memory.

[KnutJ]

Could you please point me to a valid tutorial or a thread where the usage of APIs is explained in general or specifically this api to see how i could use the GetSystemFirmwareTable API to retrieve the BIOS-Memory content in raw mode (not the values corresponding to some settings or key-value pairs)

Edited March 12, 2014 by KnutJ

[KnutJ]

... have been looking for the API i was pointed to ... but could not find a hint of how to include/use that in AutoIt in regards of solving my issue...

[KnutJ]

... looks like there is no other solution to this problem/task.

Do i really have to go on, deleting the file which is generated through the use of StdInWrite() ?

 

Could someone please edit the help-file to reflect the behaviour?

It is important to document that there may be a file (containing everything put into StdIn) every time the function is used.

[Melba23]

KnutJ,

 

Could someone please edit the help-file to reflect the behaviour?

It is important to document that there may be a file (containing everything put into StdIn) every time the function is used

Except when I run that code I do NOT get any scs#.tmp temp files formed anywhere on my system (Vista 32, v3.3.11.3) - so why should I change the Help file when you appear to be the only one affected?

M23

[jchd]

No sc*.tmp in the whole disk subsystem here either, script compiled or not, x86 or x64, using Win7 64.

[KnutJ]

Hello Melba23,

hello jchd,

good to see that this situation doesn't reproduce on Windows Vista and Windows 7,

it looks to me like this only happens on Windows Server 2003 or the very similiar WindowsXP

Unfortunately i need to use Windows Server 2003 (that's where the scs#.tmp files do get created),

maybe i will be using Windows Server 2012 in the future...

As i found out, under Server 2012 there won't be a debug command anymore.

Maybe someone could point me to a validated way to read BIOS-memory-addresses from autoit?

(the hint left by JFX didn't bring me anywhere, as i didn't find a way to read the BIOS-memory-content when looking for the "GetSystemFirmwareTable API")

Just to clarify : i do not want to retrieve ACPI, SMB or such. i need to read a specific area of the BIOS to look for a specific content. Preferably this should be working under Server 2003 & Server 2012

Greetings

KnutJ

Edited April 8, 2014 by KnutJ

[KnutJ]

I don't know why, but while the Problem persists under Windows XP (on 3 different PCs) and Windows Server 2003 (2 different Servers), it does indeed not show up on a Windows 7 Prof SP1 64bit.

As i mentioned before, i am still trying to find a way to read memory-values from the BIOS-memory-area. I do not want to read settings or properties through some abstraction/service layer, but raw memory-content from specific memory-adresses.

Any help is appreciated.

Thanks in advance