I really doubt a dongle protected software (using a parallel port) would work under DOSBox (no LPTx passtrough yet), but a SERIAL one could work.

hello eL Pusher,

Yes, I thought it should work. Especially with the TSR running to intercept the dongle-calls (presumably).

Last night I tried -disabling- the serial-port emulation in DosBox; thinking that perhaps that would keep Dosbox from 'blocking' PSAVE; but no change. Still acts like PSAVE isn't running at all.

You could try it when booting msdos/freedos on a disk image
inside dosbox, myabe it works there.

hey wd, thanks for the thought.

That never even occurred to me!

I didn't realize one could do that....I thought DosBox was already a "loaded DOS".

I will dig up msdos6.22 and try running that in dosbox.

I'm still curious what DosBox is doing differently than a real native DOS, which is causing it to block PCAD from 'talking to' the Psave TSR. Interesting...

PS: Here is the PSAVE.COM for examination, attached to this post

whups, the board wouldn't let me attach a .COM, so I changed the extension to .bak. Just change it back to .COM

whups2, the board doesn't like .bak either... 🙄

ok, i'll try it with .txt extension...

It does something with a PCADDRV.SYS. Is this file loaded in config.sys on a dos machine?

howdy hal9000, and thanks for taking a look at it.

that's a little text file which holds the locations of the drivers that PCAD uses. That file IS present in the root of C, which I'm mounting as "C" in DosBox.

PCAD is apparently finding it OK, because it gives an error if it doesn't, plus PCAD -is- opening OK, starting the graphics-editor OK; so it must be finding its drivers OK.

Contents of PCADDRV.SYS are:

SYSTEM c:\PCAD455\DRV\SIBMPC.DRV
INPUT c:\PCAD455\DRV\IMsser.DRV
DISPLAY c:\PCAD455\DRV\dibmvga.DRV

It opens one of the driver files (SIBMPC.DRV) and places a few
callback-interrupts (int e0+) in there to catch control later on.
Nothing really special/hardware related as far as i see.

hi wd,

SIBMPC is pcad's "driver" for the PC hdw, i.e. mobo...it's very generic...works on any mobo I've ever run or heard of anyone running.

Presumably pcad does its serial-i/o via this driver?

I wonder why DosBox isn't letting psave make its usual mods to sibmpc.drv ??

Or if it is, why the heck it's not working?

Note that those pcad 'drivers' are not something that's loaded in config.sys like a regular DOS driver. Pcad itself apparently loads them at runtime. And that's -after- psave is already in memory.

So Psave must be hooked into some call which allows it to see/find/modify the sibmpc.drv when pcad loads it later on...

whups....just re-read your post wd.

you say it -opens- sibmpc.drv ? On disk ??

i had at first assumed you meant it was modifying it -in ram- after it was loaded.

I wish I understood it better. All I know is that there's still something in DosBox emulation that isn't 100%. This psave thing works flawlessly under a normal DOS boot environment.

They open the file sibmpc.drv on the disk, insert some code (cd e0)
and stay resident (hooking int e0+), now when that code in sibmpc.drv
is executed, the int e0 calls psave. At this point i can't really tell what
it does exactly, changes some registers for one call, and looks like it
does memory patching on other cases as well.

huh....interesting that it changes the file on disk every time it runs.

just making sure, I guess....grin...

I looked through psave in an editor and saw the list of error msgs. psave is running without displaying any error msgs; so I'm assuming that it's finding the pcaddrv.sys and ibmpc.drv files ok....and likely writing the changed version back OK.

Unless Dosbox is not letting the changed version actually get back to disk? Is psave using dos disk i/o, or direct bios calls?

Perhaps dosbox or Win2K isn't allowing the changed version to make it back to disk...so when PCAD runs after Psave, it's loading an unchanged version into memory??

Could one of the DoxBox developers take a look and see if they can spot what DosBox is doing differently than DOS in this case?

You could also try a CVS version of Dosbox.

There's nothing wrong about that psave, they're using standard
dos file access. Unless you have some of the files from that
program read-only or otherwise limited access, this should not
impose any problems to the code writing.

hi wd,

Nope, files are accessible and writeable.

No idea what's happening then, as most code is executed in the
main program/driver files. Could be that the drivers are loaded
through a device driver interface, which isn't supported down to
the lowest level in dosbox. Trying the program under dosbox when
booting msdos should be working then.
Otherwise it might be something with the emulated hardware,
as HAL suggested you should try a CVS build of dosbox.

hi wd,

I believe that the pcad exe's are loading the drivers themselves.

I didn't find anything about HOW to load/run/start a regular DOS within DosBox. Maybe I missed a link somewhere?

I don't know anything about "CVS", sorry.

I find much of the sourceforge stuff to be simply impenetrable; as if it's purposely written to be obscure; understandable only to linux/C programmers....keep the club exclusive or whatever.

I have worked with computers since keying in my first octal on the front-panel of a DEC PDP-11/45 in 1974...and have written various small things in BASIC and 8086/6502/PIC assy over the years, for testing hardware products. So I'm not totally ignorant software-wise.

But not much on sourceforge is written from a motivation to be CLEAR and EASY TO USE to those who are NOT C-programmers.

It may be great for the 1% exclusive-club, but 99% of the people in the world can't make use of it, and never get a chance to appreciate the coding-skills etc.....so 99% of the stuff on sourceforge just sits there and never gets used and loved....unfortunately.

Appreciate you taking a look at this pcad/psave thing. I could probably post the pcad exe itself...I think it's only 300-400K, if I remember right. I'd have to try a new dir with only the EXE, and see what else it yells for, if anything.

Go ahead, archives below 5MB are ok.

dozer wrote:

I didn't find anything about HOW to load/run/start a regular DOS within DosBox. Maybe I missed a link somewhere?

There are basically two steps: Mount a disk image, then boot from it. I hope you know about disk images, they're basically dumps of whole floppies or hard disks to a file, partition table, headers, file allocation table, root directory, and all. A real dos inside dosbox can work only with files contained inside such images, not with files in your file system. This is because of the way a real dos works: it expects to see a hard disk or floppy that's simply divided into evenly sized sectors readable through the BIOS. You mount an image using the IMGMOUNT command in dosbox (only needed for hard drive images, not for floppies), and boot from it with the BOOT command. Both commands will give short explanation texts when you type them without any arguments. Images can be made from real disks with WinImage or similar software; or you can simply create a large enough file with whatever kind of junk in it (zeros for example), and then treat it like you would a factory new, empty hard drive: Boot your dos from floppy images, then FDISK and FORMAT the hard drive image, install DOS to it, and then copy in your software with DOSBOX's COPY command (this has to happen between IMGMOUNT and BOOTing).

I don't know anything about "CVS", sorry.

CVS is a system for managing a changing source code tree. "CVS builds" are versions of dosbox created directly from the source tree as it is at the time, basically you can think of them as unofficial releases of dosbox. You don't need to create them yourself from the source code, there are several people who offer ready-made CVS builds on their web pages with some regularity. There is a "sticky" thread about these somewhere in the forums.

I find much of the sourceforge stuff to be simply impenetrable; as if it's purposely written to be obscure; understandable only to linux/C programmers....keep the club exclusive or whatever.

Well, sourceforge is a source site as the name implies. Not limited to linux and C by any means. But you should have and know how to run a compiler. And C and C++ are simply the most commonly used language on sourceforge. C is pretty easy to pick up if you have some experience with assembly.

But not much on sourceforge is written from a motivation to be CLEAR and EASY TO USE to those who are NOT C-programmers.

Well it's *source*forge, not *executable*forge.

It may be great for the 1% exclusive-club, but 99% of the people in the world can't make use of it,

Most of the popular projects have fairly regular releases, and the Windows versions of those usually don't require any compiling. Just download and install.