Are you sure this is a DOSBox problem? Do you know whether the program behaves the same way under real DOS?

Maybe the cursor isn't actually supposed to show if anything is being typed, so an observer would be unable to see the length of the password as it is typed in.

Also, DOSBox IS NOT SUITED TO RUN YOUR NON-GAMING DOS APPLICATION .

I believe that it is a DOSBox problem. l have used the dbase IV program for years under real DOS, even with encrypted files.
And I personally encrypted the files that I'm trying to access now.
The dBase people also now sell a program that uses a modified version of DOSBox to allow printing.

The logon screed normally allows the password to be typed and seen as it's typed.
I suspect the problem could be that the file which contains the password is encrypted but I don't know what to do about it.

Coastal wrote:

I suspect the problem could be that the file which contains the password is encrypted but I don't know what to do about it.

That sure doesn't sound like a DOSBox problem.

that somehow DOSBox is preventing dBase from reading the encrypted file that contains the password.

Perhaps the file should have attributes like System, Hidden, or Read-Only, and the app insists on finding those. Seems plausible for a password file, and if it's true then the app won't work correctly with DOSBox's emulated DOS. It doesn't matter how you set file attributes in the host file system, DOSBox won't see them. The app may need other specific DOS features as well, but of course you can try running the app with a disk image and booting real DOS in DOSbox -- or better yet, use a VM intended for running DOS apps.

PROTECT builds and maintains a password system file called DBSYSTEM.DB, which contains a record for each user who accesses a PROTECTed system. Each record, called a user profile, contains the user's log-in name, account name, password, group name, and access level. When a user attempts to start dBASE Plus (if dBASE Plus is configured to require a log-in to start the program), or attempts to access an encrypted table (if dBASE Plus is configured to require a log-in when an encrypted table is accessed), dBASE Plus looks for a DBSYSTEM.DB file. You can specify a location for this file in the [CommandSettings] section of PLUS.ini:

DBSYSTEM=C:\Program Files\dBASE\Plus\BIN

If there is no DBSYSTEM entry in PLUS.ini, dBASE Plus looks for the file in the same directory in which PLUS.exe is located. If it finds the file, it initiates the log-in process. If it does not find the file, there is no log-in process.

why not try dbase for windows
http://www.dbase.com/dbasesql/trial/

when I encrypted the files, dBase IV (not dBase Plus) wrote the files
dbase420.acc, dbsystem.db, dbsystem.sql, and login.db. All of these files
are located in the same directory with dBase.exe

I believe that dBase finds dbsystem.db when the logon screen appears,
but I guessing that it then looks for the encrypted login.db file, and can't read it.

The dBase program worked correctly with these encrypted files, when I last
used it under Vista without an emulator.

Coastal wrote:

that somehow DOSBox is preventing dBase from reading the encrypted file that contains the password.

While it's not impossible, it is very unlikely that there is something about the encryption that would interfere with DOSBox. A file is a file, encrypted or not.

Coastal wrote:

The dBase program worked correctly with these encrypted files, when I last
used it under Vista without an emulator.

How are you mounting your directories? Do the mounted folders have the same paths that the program used when you were running it in Vista?

I currently have the directories dBase IV and database both mounted under c:\dosprgs

c:\dosprgs\dBase IV
C:\dosprgs\database

They were located similarly in Vista
They also worked correctly in Vista when database was located in a remote directly,
but dBase IV was started from the database directory.

"Similar?" The computer doesn't care about "similar".

When you run DOSBox, what folders are you mounting? Are you mounting c:\dosprgs as drive C, or what? Considering DOSBox cannot recognize folders with spaces (like "dBase IV"), it is amazing it works at all.

You're right--I wrote that too quickly.
I'm mounting c:\dosprgs as drive C,
and the folder name isn't "dBase IV" as I've shown, it's name is just "dBase".
I don't use more than 8 characters and no spaces in a file name.

Okay, and when you were running it in Vista, did you have folders exactly named C:\dBase and C:\database, or were they something else?

try copying DBSYSTEM.DB to the same folder as protect.exe

There is no file named "Protect.exe"
All of the program files for dBase IV are in one folder

Jorpho wrote:

"Okay, and when ou were running it in Vista, did you have folders exactly
named C:\dBase and C:\database, or were they something else?"

Yes, thery were named exactly the same.

Ripsaw8080 wrote:

"Perhaps the file should have attributes like System, Hidden, or Read-Only, and the app
insists on finding those.
Seems plausible for a password file, and if it's true then the app won't work correctly
with DOSBox's emulated DOS. It doesn't matter how you set file attributes in the host
file system, DOSBox won't see them."

Thank you VERY much.
I find that the login file DOES contain a Read Only attribute. So I guess that must be the reason I can't
enter a password.

Can you recommend a VM that might work with dBase IV encrypted files ?

Coastal wrote:

I find that the login file DOES contain a Read Only attribute. So I guess that must be the reason I can't
enter a password.

I doubt it. But if it does come down to attributes, you can still use DOSBox provided you use disk images and boot a real version of DOS, as in Install DOS in DOSBox .

What happens if you clear the read-only attribute in Windows? Are any other files read-only? The program might simply be trying to write to a file that it cannot write to.

Can you recommend a VM that might work with dBase IV encrypted files ?

VMware, VirtualBox, or Virtual PC will all probably work equally well. You can even use Vista or XP inside the VM if you want, though that would be overkill.

I cleared the Read-Only attribute, and there is no difference--I still can't enter a password.

I still have an old copy of DOS, but it's on 5-1/4 in. floppies, and I don't know how I would get it onto my machine.

I've begun to look into the VM's suggested, but at first glance, they seem to be more difficult to handle than DOSBox.

You don't really need all of DOS; any ordinary boot floppy (or image of a boot floppy), even from Windows 95 or 98, will do fine. Such floppy images are easily found throughout the Internet. FreeDOS will also probably do the trick.

Coastal wrote:

I've begun to look into the VM's suggested, but at first glance, they seem to be more difficult to handle than DOSBox.

Not really, especially if booting into DOS is necessary. The other alternative would be to get Windows 7 Professional or Ultimate, which includes XP Mode.

Or you can switch to Windows 7 32-bit if you really want to and don't really need to use 8 GB of RAM.

Coastal wrote:

I cleared the Read-Only attribute, and there is no difference--I still can't enter a password.

Did you only change the attribute for that one file? Were there no other files that had the read-only attribute?