I'm creating a GTest project which needs to simulate input into scanf of the current process.
I used GetStdHandle() in order to get handle to stdin of current process, but WriteFile seems to fail due to "Invalid Handle" (6).
How then can I put data in stdin for scanf to read?
I'm using Microsoft Visual Studio in case it matters.
Thank you.
Related
I was trying to run Visual Basic 4 (16-bit) in Windows 3.1 running within DosBox. However it failed to launch with error:
SHARE.exe must be installed in order to run Visual Basic
Some old MS-DOS applications just check for existence of the EXE and it's presence in autoexec.bat, but in this case the EXE exists, but the error still occurs.
Running on Windows 7 32-bit and using a debugger attached to NTVDM.exe I found the following process is used:
A Temp file is created with GetTempFilename
Call to LockFile API
Call to UnlockFile API
When I set a breakpoint at return of LockFile API and faked a faliure (returned false) On Windows 7 I got the same error message "SHARE.exe must be installed in order to run Visual Basic"
However within the VB.exe I can't find any reference to LOCKFILE API, so I suspect NTVDM.exe is translating it somehow.
The APIs that seem potentially related in the import table of VB.exe are:
Kernel!OPENFILE
Kernel!_LWRITE
Kernel!_LREAD
Kernel!_LOPEN
Kernel!_LLSEEK
Kernel!_LCREAT
Kernel!_LCLOSE
OLE2!OLELOCKRUNNING
Kernel!LOCKRESOURCE
Kernel!LOCKSEGMENT
I am trying to work out how the lock / unlock file test is done so I can try to remediate within DosBox and create my own test program to replicate in C or VB.
SHARE.exe must be installed in order to run Visual Basic
SHARE.EXE works as Terminate and Stay Resident kind of program. So it existence is not enough. It must be run, to hook into system and intercept some requests.
SHARE.EXE intercepts DOS Interupt (0x21) and DOS Multiplex Interrupt (0x2F).
In 0x21 interrupt code 0x5c handles locking and unlocking files
http://www.techhelpmanual.com/530-dos_fn_5c00h__lock_file_access.html
LockFile 5c00h
Expects:
AX 5c00H
BX file handle
CX:DX file offset from start of file (CX * 65536)+DX
SI:DI length in bytes of region to lock (SI * 65536)+DI
Returns: AX error code if CF is set to CY
This function locks access to a region of the file identified by the file handle in BX. The region of the file that begins at file logical offset CX:DX extending for a length of SI:DI is locked ...
http://www.techhelpmanual.com/531-dos_fn_5c01h__unlock_file_access.html
UnlockFile 5c01h
Expects:
AX 5c01H
BX file handle
CX:DX file offset from start of file (CX * 65536)+DX
SI:DI length in bytes of region to lock (SI * 65536)+DI
Returns: AX error code if CF is set to CY
This function unlocks access to a region of the file which was previously locked...
You could also check 5dh functions marked mostly as internal.
Implementation in Free DOS:
https://sourceforge.net/p/freedos/svn/HEAD/tree/kernel/trunk/kernel/dosfns.c
see DosLockUnlock function
https://sourceforge.net/p/freedos/svn/HEAD/tree/kernel/trunk/share/share.c
Looking at vDos source code could help if you plan to bring this funcionality to Dos Box
https://sourceforge.net/projects/vdos/files/Version%202015.04.10/
However within the VB.exe I can't find any reference to LOCKFILE API
I'm not sure if LockFile existed in Win16 (probably not), but there is possibility that sharing API is called directly through DOS interrupts.
I suspect NTVDM.exe is translating it somehow
I don't know it for sure, but I would assume that it intercepts DOS interrupts and uses Win32 API calls to simulate needed behavior.
I am trying to work out how the lock / unlock file test is done so I can try to remediate within DosBox and create my own test program to replicate in C or VB
I would try to log INT 21h and INT 2Fh calls in DOS Box.
I have native win32 application that starts Qt exe application with (probably ) CreateProcess function
The Qt application doing some work , now when the Qt application done its job I need it somehow to signal back with returned parameter
String type . what is the best way to implement such thing ?
I'm not sure if this solution is to trivial for you but here it is anyway:
a) let the Qt application write something on stdout, the calling win32 application should be able to read it and parse it.
b) You could for a brief moment use the windows clipboard QClipboard
c) You could write a temporary file containing the string.
Best regardsD
I think I would use stdout to communicate this. When you call the process create a file in a temporary location and pass its handle to the new process as stdout. Then wait on the newly created process handle. Once the process finishes read the information out of the file.
We have an in-proc crash handler which is using MiniDumpWriteDump() from DbgHelp to write a minidump is case of a process crash.
I know its not the best way to do it, however, at the moment we do not have other option.
The problem is: one certain executable always creates 0 byte dumps. But it works well for other processes. What could be the possible reason behind this behavior?
We had this problem from time to time with our minidumping code. In the end we changed it to spawn a lightweight secondary process on startup and used a simple MMF to communicate with the dumper process when we needed a minidump generated.
We had all sorts of problems using MiniDumpWriteDump from within the process being dumped. Since the change to a dedicated dumping process, it's been very reliable.
If at all possible I suggest you consider the same. It ended up not being that much work.
Exe made in vb6 will hang if its continously run on server? This exe has winsock component which is used to received data from biometric readers and saved in sql server 2005. Actually this shows real time list for acceess made on biometric readers means in this exe we have used datagrid component which display saved records in sql. How to refresh this exe and data.?
Well, if you're displaying a GUI then I'd say technically you are not running on a server. But I still don't see how doing this will make the program "hang."
There are some things to be careful of when it comes to VB6 memory leaks. One thing to be sure to do is make sure you use the SP6 version of the VB6 runtime and "extended runtime" (the set of controls that ship with VB6). The other is probably to go over the code and look for circular object references that may result in accumulated orphaned objects over time. There were also a few obscure ADO memory leaks that never got fixed until MDAC 2.7, but most of those don't impact a VB6 program.
I suspect there are other causes of hangs, but most of those are probably faulty logic such as loops containing DoEvents calls. Using Winsock for TCP without a full understanding could also produce programs that seem to work at times and then hang awaiting something that nevers happens other times. Remember, on every DataArrival event you can count on at most one byte of data - you need to write your own stream assembly and message parsing logic. One SendData call at a sender does not equal one GetData call at the receiver!
Sent: abc
Received: a
bc
If the program calls GetData until it gets "abc" it will never see it!
Background: We develop win32 applications, and use the "Thompson Toolkit" on windows to give us a unix-like shell that we use as our command-line.
We have a GUI program (with a WinMain and message loop) that we want to write to the console, but printf and so on don't work, even when we launch the program from the console. How can we write to the console from a GUI program? We need to print text there so that an automated build system can display error messages and so on.
Thanks.
In short, you need to attach a console. For details and ready to use code, see http://www.codeproject.com/KB/dialog/ConsoleAdapter.aspx.
Basicly you have to create a console by your self with AllocConsole, AttachConsole. After that you have to get standard handles with GetStdHandle and "associates a C run-time file descriptor with an existing operating-system file handle" with help of _open_osfhandle.
The returned handle can be used to overwrite crt stdin and stdout. After that all crt methods like printf should work.
Instead of logging to the console, log to a file and then track the file with a separate gui application. This keeps the console uncluttered and gives you a more persistent record of your log, which occasionally is extremely useful. There are various libraries which will do most of this for you, or you can keep it simple and just do it yourself.
somewhere in the Visual Studio Project Settings you can switch on having a console, assuming you are using VS. (Can't say where because I currently don't have it)