Log in

View Full Version : How to Identify/leverage a database system in a 16bit DOS application


are
January 23rd, 2011, 14:44
Ok, so I've got this program that only works on windows 98 SE or before. It's DOS, and seems to be 16bit. The application is a business's point of sales system so it helps scan items and come up with prices for that item, (it also does inventory management, customers management, the works).

I've been trying to pull information out of it with some success... I need to use it's DOSy interface, and read it's DOSy plain text reports. It's grueling and inefficient and I can't figure out how to dump the whole database into plain text where I can peruse and parse the information. When I print out a report, it displays this loading screen showing the strings { SELECT, SORT, MERGE, PRINT } followed by the percentage of completion (It rifles down the list, you know what I mean). I didn't know it at first, this isn't my area of study, but I'm starting to think that sounds like database talk!

So, I've been studying database information systems and I'm wondering if it's possible that I might be able to override the programs built in SELECT query with my own, thus outputting what ever I want from what ever database they're using. Or maybe I should try to identify the database they're using and extracting the data through a ready-built frontend that allows you to do queries against the data.

So...

How can one identify the database system?
There's dozens of EXE files associated with this application. I think I found physical databases...


I used FileMon.exe and noticed access to CUSTSLS.G03 when probing year 3 sales by customer...
And Custmas.gsg seems to be the customer master list database (full of human readable string regarding customer's accounts)


What should I break point to get access to the SELECT command string?
I have zero experience working with 16bit apps. I'm very discouraged to not know what tools to pick, or how to use them. I remember reading a softice tutorial a long, long time ago, and I think I clung on to that binary, but I'm operating in a Virtual machine atm which I understand might complicate things. Visually, on the app, I am prompted with a "dialog box" that asks,

Caption: "Routing Ticket",
Message: "Route report to:"
And my options are "Printer" or "Mail" (mail writes a .rpt to the hdd).
I can use left arrow or right arrow to select either printer or mail and then hit enter. The following screen would display the progress screen (SELECT 100%, SORT 100%, MERGE 28%, PRINT 0%).

So what kind of a thing should I break on? For that matter, how do I get a list of things to break on from the .exe?


Or where would I find the hard-coded queries?
There are SO many files! It's prohibitively ridiculous. That's why I haven't just sat around perusing. But maybe there's a trick to it? To begin the program, you click START.exe. After that it's a mystery of hdd writes and reads.

Woodmann
January 23rd, 2011, 18:51
Quote:
Or maybe I should try to identify the database they're using and extracting the data through a ready-built frontend that allows you to do queries against the data.


That would be the easiest way

Woodmann

BanMe
January 23rd, 2011, 19:32
heres a start though

http://msdn.microsoft.com/en-us/library/ms713553%28v=vs.85%29.aspx

something here interested me..

http://www.files32.com/Company-redei_enterprises.asp

are
January 24th, 2011, 01:36
Kk, thx all. Looks like it can't be using those MS ones since it's definitely all 16bit (just double checked, wdasm decompiles a very dry, stringless mess of 16bit stuff). I'm thinking it's database might be something custom built so I'm just goona move on. I stumbled across another report type that allows me to dump way more information than I thought I could before, so I probably won't be missing much.

BanMe
January 24th, 2011, 09:43
grdb and 'debug' are 16 bit debuggers..the MS link says it also applies to 16bit applications..I showed the link to the 16 bit database explorer because it might just be that interface u need :d

aqrit
January 24th, 2011, 13:26
FoxPro was a common DOS database

IMO the best way to debug a DOS program...
( If the program will run in DOSBox )
Compile DOSBox from source and use the built-in debugger
You can use TSR programs and other DOS debuggers inside DOSBox (sans hardware breakpoints)
You can also use modern day tools on the DOSBox process ( IDA, Olly, Cheat Engine, etc. )

disavowed
January 24th, 2011, 13:45
FYI, Turbo Debugger was one of the better 16-bit debuggers.