Windows equivalent of TSR? Getting Windows programs to interact

[DaveC426913]

TL;DR Summary

How can I write a script that will sit over top of another program and operate it? eg. data entry?

I have a data entry program in Windows 10 that has no API to interface with it directly.
I have a lot of data to enter manually, which is very slow.

Assuming I can get that data into a digital form and store it in a .CSV file or clipboard, how can I write a utility app that will sit over top of the data entry program and fill in the fields with the provided data - and with my guidance?

In DOS days, these were called TSRs (Terminate and Stay Resident). You would open your program and press a key sequence to activate the TSR, which would operate on the open program.

Example:
I have a dozen members, eg: #1 - Bob Smith, ID #23423; .
I manage to store that in a .CSV file or the clipboard (with appropriate record and field delimiters)
I open my data entry program to the "Add member" form.
I put the first field in focus and press a key.
The data is spewed into the field(s).
I manually advance to the next record in the application Or have my script program do that, by sending a Ctrl-F followed by some search criteria.

There's a lot more to how I want to go about this. Right now, I'm just trying to get the programmatic output of data from a file or clipboard.I don't want to do this in C# or C++ or Java or something else super-powerful and super-complex, if I can help it.

 

[Dr Transport]

alot of times you can insert the command for the execuatble as the first element in the line followed by the input data i.e.

something.exe Bob Jones 234674
etc...
into a something.bat file that you can run from the command window.

 

[Ibix]

It may be possible with Excel VBA. Moving the mouse:
https://wellsr.com/vba/2015/excel/vba-mouse-move-and-mouse-click-macro/
Sending keystrokes:
https://www.contextures.com/excelvbasendkeys.html

Feels like a gigantic security hole, however, so this kind of thing may be locked down a bit in Windows 10. Both articles appear to pre-date it.

 

[Klystron]

Concur with @Dr Transport. I found a decent tutorial on creating batch files and MS-DOS commands. I used to have a collection of useful DOS command files but mainly for device controllers and network stuff long before Windows 10.

https://www.computerhope.com/overview.htm

I imagine you can format your data entries into a batch file opened by another batch.

 

[sysprog]

I suggest looking at https://www.autohotkey.com. You can see some of its capabilities at that site, and at https://rosettacode.org/wiki/Category:AutoHotkey.

You could also look at Windows Script Host -- https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/wscript and at Powershell -- https://docs.microsoft.com/en-us/po...ted-with-windows-powershell?view=powershell-7

For what you're apparently seeking to do, I think that autohotkey is probably the best and most versatile facility.

 

[PeterDonis]

In DOS days, these were called TSRs

Ah, memories...

Unfortunately (or fortunately, depending on how you look at it), the reason this was so easy in the DOS days was that DOS had no security model; any process was root on the machine, so it could install arbitrary interrupt handlers (among other things). So you would just install a handler on whatever interrupt the other program was using to read data (since DOS system calls were all interrupt 21, that was the most likely handler your TSR would install), and massage the data that would be sent to the other program however you like. And since DOS could also only run one non-TSR program at a time, you didn't have to worry about your TSR sending massaged data to the wrong program.

Windows has neither of those features of DOS: it does have a security model (not a great one, since it was bolted on as an afterthought instead of being designed in from the start, but it does prevent arbitrary programs from doing things like installing interrupt handlers and other ways of monkeying with input data), and it can run multiple programs at a time. Generally, the way Windows programs communicate with other programs is by sending messages, but unless you have access to the source code of the data entry program or can run it with a debugger, there might not be any easy way of figuring out how to send it the right messages.

 

[jedishrfu]

You might look at GUI testing tools where you can write a script to test a GUI fill in fields, make selections and press buttons...

Heres one such solution:

https://www.leapwork.com/discover/g...CuJM0kPbX1dCj32uPMVT7Ww8-WdnJNlcaAshDEALw_wcB

you might others via a google search.

 

[Tom.G]

Here is a Redirection Port monitor called 'RedMon' written for up to Win7.
http://www.ghostgum.com.au/software/redmon19.htm

And here are instructions to install it on Win10.
http://www.iotti.biz/?p=730

Basic operation is it creates a new Print device that then redirects the data to the StdInput of the program of your choice.

(search terms were:
https://www.google.com/search?&q=windows+10+input+redirection+port
https://www.google.com/search?q=redmon+alternative+windows+10)

Cheers,
Tom

p.s. Let us know if it works... sounds useful!

 

[Mark44]

So you would just install a handler on whatever interrupt the other program was using to read data (since DOS system calls were all interrupt 21,

Technically, the DOS functions were accessed via interrupt 21h (33 decimal). With the release of MSFT Windows 95, access to the int 21h DOS functions was no longer available. This broke a bunch of small x86 assembly programs I had written.

 

[sysprog]

Technically, the DOS functions were accessed via interrupt 21h (33 decimal). With the release of MSFT Windows 95, access to the int 21h DOS functions was no longer available. This broke a bunch of small x86 assembly programs I had written.

You didn't opt to run them via NTVDM?

 

[PeterDonis]

the DOS functions were accessed via interrupt 21h (33 decimal)

Yes, I was so used to thinking in hexadecimal when writing DOS programs that I didn't think to put in the "h". (In the assembler I typically used back then, hex was the default for targets of instructions.)

 

[Mark44]

You didn't opt to run them via NTVDM?

No, it wasn't so important that I run them.
BTW, one of the programs had a C main() that called an assembly subroutine to change the name of a directory. At the time (late '80s/early '90s), there was no capability in DOS to rename a directory. At the college where I worked, there was an Intro to Computers class. In the class they taught students to 1) create a new directory (MD command), 2) copy the files from the old directory to the new one, 3) delete the files in the old directory, and 4) delete the old directory (RD command). Norton Utilities had a routine that renamed a directory, and with a bit of disassembling, I figured out how they were doing it -- by calling the DOS interrupt to rename a file. I didn't realize at the time that the only difference between a file and a directory was that in the file attributes, there's a bit that is on for directories, and off for files.

 

[sysprog]

Yes, I was so used to thinking in hexadecimal when writing DOS programs that I didn't think to put in the "h". (In the assembler I typically used back then, hex was the default for targets of instructions.)

I still write IBM mainframe system code, and, as you know, when we want to be explicit about the base, we put it in advance; not afterward -- as in X'10' or B'10000' or D'16'.

 

[PeterDonis]

I still write IBM mainframe system code, and, as you know, when we want to be explicit about the base, we put it in advance

I believe the original IBM PC assembler did this; you would write int 0x21 for the DOS interrupt. IIRC it was Microsoft's assembler that started the following "h" convention.

 

[pbuk]

I believe the original IBM PC assembler did this; you would write int 0x21 for the DOS interrupt. IIRC it was Microsoft's assembler that started the following "h" convention.

These conventions predate both the IBM PC and Microsoft.

The trailing "h" (or in some versions a capital "H") was used in the Intel assembly language (now known as "x86 assembly language") at least as far back as the 8080 in 1974 MCS-4 for the 4004 in 1971.

I think the 0x21 notation comes from PDP assembly language, possibly as far back as the 50s.

 

[PeterDonis]

These conventions predate both the IBM PC and Microsoft.

Interesting background, thanks!

 

[FactChecker]

You can make a script program using the language of your choice (DOS, Perl, Python are popular). The options for communicating with the application depend on how well the application is designed for it. In order of ease of implementation (IMHO), here are 3 possibilities:
1) Some allow command-line control through DOS.
2) Some are set up for OLE.
3) Some may require that you use SentKey to send keyboard characters to the application.
Each of these requires a significant learning curve. If you decide on an approach, you may be able to get detailed help on that.

 

[PeterDonis]

Some allow command-line control through DOS

Not sure what you mean by "DOS" since we're talking about a Windows 10 machine.

 

[FactChecker]

Not sure what you mean by "DOS" since we're talking about a Windows 10 machine.

I mean the commands that are available in the command prompt window.

 

[robphy]

As @sysprog suggests, I also recommend https://www.autohotkey.com/ .
I use it everyday for various tasks on my computers, especially when I use the stylus and don't have easy access to a keyboard.
Here's an example I wrote to try to solve a problem
https://www.physicsforums.com/threa...sed-with-ocr-applications.953427/post-6051395