Windows equivalent of TSR? Getting Windows programs to interact

  • #1
DaveC426913
Gold Member
18,776
2,256

Summary:

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

Main Question or Discussion Point

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.
 

Answers and Replies

  • #2
Dr Transport
Science Advisor
Gold Member
2,371
497
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.
 
  • #4
Klystron
Gold Member
685
933
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.
 
  • #5
1,442
760
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.
 
  • Like
  • Informative
Likes robphy, pbuk and Klystron
  • #6
PeterDonis
Mentor
Insights Author
2019 Award
29,591
8,883
In DOS days, these were called TSRs
Ah, memories... :wink:

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.
 
  • Like
Likes sysprog
  • #8
Tom.G
Science Advisor
3,232
1,978
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!
 
  • Like
Likes harborsparrow and sysprog
  • #9
33,631
5,287
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.
 
  • #10
1,442
760
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?
 
Last edited:
  • #11
PeterDonis
Mentor
Insights Author
2019 Award
29,591
8,883
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.)
 
  • Like
Likes sysprog
  • #12
33,631
5,287
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.
 
  • Informative
  • Like
Likes sysprog and Klystron
  • #13
1,442
760
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'.
 
  • #14
PeterDonis
Mentor
Insights Author
2019 Award
29,591
8,883
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.
 
  • Like
Likes sysprog
  • #15
pbuk
Science Advisor
Gold Member
1,427
405
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.
 
  • Like
Likes sysprog
  • #16
PeterDonis
Mentor
Insights Author
2019 Award
29,591
8,883
These conventions predate both the IBM PC and Microsoft.
Interesting background, thanks!
 
  • Like
Likes sysprog
  • #17
FactChecker
Science Advisor
Gold Member
5,578
2,056
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.
 
  • Like
Likes sysprog
  • #18
PeterDonis
Mentor
Insights Author
2019 Award
29,591
8,883
Some allow command-line control through DOS
Not sure what you mean by "DOS" since we're talking about a Windows 10 machine.
 
  • #19
FactChecker
Science Advisor
Gold Member
5,578
2,056
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.
 
  • Like
Likes sysprog
  • #20
robphy
Science Advisor
Homework Helper
Insights Author
Gold Member
5,627
883
  • Like
Likes sysprog

Related Threads on Windows equivalent of TSR? Getting Windows programs to interact

  • Last Post
Replies
2
Views
2K
Replies
13
Views
5K
Replies
5
Views
4K
Replies
1
Views
3K
  • Last Post
Replies
3
Views
3K
  • Last Post
Replies
3
Views
6K
  • Last Post
Replies
11
Views
4K
  • Last Post
2
Replies
38
Views
2K
  • Last Post
Replies
5
Views
4K
Top