Bjorn Simonsen said:
You are right. I have patched som other programs in the past, but not
these. Should have reconzied the error, bummer. Oh well - but I did
now
. Thanks.
You know, I hadn't been aware of the patch until after the one summer where
I'd gone through and deleted all DOS programs that gave me the error. Not
asking for sympathy -- it wasn't quite so tragic as it sounds. They were
mainly just a lot of "eye-catching" downloads that I'd archived over time,
and not programs that I'd got much involved with.
I have to unpack the files before I can apply the
patch. But just tried for testing, loaded a TSR patch (TP7P5FIX.ZIP)
before running the app, then the program runs just fine.
I decided to do the same, with the DO.exe that you posted about, as my
test subject. I'll outline my story here (having in mind those that need
to do the same kind of thing, as well as those who might know of better
tools than the ones I found).
Your telling me that it was a packed exe probably served me as something
of a time-saving clue. Otherwise I might have wasted time wondering why
a series of the Pascal patchers were not working, before it occurred to
me that it was compressed.
I regularly use tools that tell me when a PE is compressed and tools that
can unpack in the common cases - namely, UPX and ASPack. Thing is, I
didn't have experience dealing with this for the case of DOS executables.
So tonight I searched for tools that would tell me about a DOS exec's
compressor, and also do the unpacking.
The two I found that both worked to tell me about the file: WHATIS and
GetType.
http://www.exetools.com/file-analyzers.htm
http://www.exetools.com/files/file-analyzers/whats203.zip WHATIS
http://www.exetools.com/files/file-analyzers/gtw.zip GetType
http://philip.helger.com/gt/p_gt2.htm (homepage for GetType)
They said: PKLITE 1.15 extra compression.
So next, I needed an unpacker. I was rather hoping for an all-in-one tool,
that would handle not only pklite but say also wwpack, lzexe, and similars.
Yet the handful I downloaded that presented themselves this way didn't work
for me. The one that did do the Pklite decompress successfully, that was
DISLITE.
DISLITE, expands all PKLITEd files to original
ftp://ftp.simtel.net/pub/simtelnet/msdos/execomp/dislt115.zip
Last, the patch. There are a number available. I notice that the DOS site
at cox.net gives a good overview of the situation, a very good description
about the three approaches, including factors to determine which route to
take. Especially, TSR vs altering the executable.
http://members.cox.net/dos/misc02.htm#bp7pat
If I were in a business environment, wanting to err on the side of caution
as far the letter of the law, the need would usually be to choose the TSR
approach. Tonight, what I chose to use was a patcher:
TPPATCH ftp://garbo.uwasa.fi/pc/turbopa7/tppatch.zip
or
TPpatchWin, a GUI frontend for TPPatch.exe
http://www.ifrance.com/snoopy81/ToolsE.htm
And this one worked smoothly. All systems "Go."
But just tried for testing, loaded a TSR patch (TP7P5FIX.ZIP)
before running the app, then the program runs just fine.
The LFN issue is another thing of course, particular for file utils,
Yeah the LFN divide, it meant an entire population of casualties.
so I will probably not be using any of these on my 2k machine anyway...but
it is nice to "see them" again
Heh!! The old familiar faces. Visiting us in our new town just briefly, but
how it's good to get to say, "Hi!" and maybe do lunch.
One of the utilities is DO.EXE, review (yours truly somewhat
involved
and link here
<
http://members.cox.net/dos/fileuti3.htm#other>.
Nice thing with this program - you have all commands and syntax in
front of you. No need to go diving into command /? and
pages of help screens, or to memorize any cryptic syntax, when its all
"in our face"...Ditto with that some of the commands have /T switch
for test run - see what you DO before you DO it
This would have been especially cherished in the old days, when stranded
at the black console (not able to multi-task over to your documentation,
and lists of tools).
I just love the manual, excerpts follows - to show you why:
[...]
DO does DOS ops like a daemon, but it does not write its own
docs. DO does so much that it was determined that all the time
and effort that the program saved us in network administration
could probably be lost to the task of writing a manual for its
use. DO was developed with the idea of having to DO less. So
writing a manual, we did not DO."
</quote>
Heh, that is a good point they make, the contradiction that is would be
for them to waste time in writing a manual when the utility's raison
d'etre was saving time.
Love it!
Agree, great sense of humor.
What a loss, Bremer Corp. Maybe I should light a candle tonight, in
memorial...
