DOS app annoyance

[Carmine Castiglia]

This is one of those thinks that just annoys the heck out of me...

I have an old DOS database app, RBase, which I haul out once a year when we
do inventory of a medium-sized manufacturing facility. Sure, it's old, but
I have extensive database scripts written for it and it gets the job done
nicely. For its once a year usage, I have seen little reason to dump it.

Here's the problem: The app runs perfectly in a DOS window on my home PC's -
both desktops and notebook - but will not run on two of the office PC's
which I have tried it on. All of the PC's are similarly configured with XP
Pro/SP2 (and all available updates), all have fast P4 processors (>2 GHz)
and large NTFS drives, the desktops have 1GB ram, 512MB in the notebook.
All have identical %systemroot%\System32\Autoexec.NT and Config.SYS files.
The NTVDM related files (ntvdm.exe, ntio.sys, ntdos.sys) which I have
reviewed appear to be identical as well. The app's properties (Memory,
Screen, Compatibility, etc) are configured identically on each of the
systems.

On the office PC's, trying to run the main executable (RBase.exe) within a
"Command" window crashes with results similar to those described in
http://support.microsoft.com/kb/245184/en-us. On the other hand, if I
simply double-click the executable (or run it in a "Cmd" window) a DOS
window opens but the app never starts. The window remains black with a
white cursor which just sort of zips around within in somewhat diagonal
patterns (if the app were to start up, the window would have gone to a
white-on-blue text window drawn with the ASCII box drawing characters). I
eventually have to force the window closed by killing the app.

Both of the office PC's have no trouble running DOS apps in general; I can
open command windows and execute common commands without incident. I have
reviewed http://support.microsoft.com/kb/156687/en-us and
http://support.microsoft.com/kb/314106 but gotten nowhere.

FWIW, the office PC's are Dells which came preloaded with XP. The home PC's
are running retail copies of XP.

Any thoughts as to how to get this fixed would be greatly appreciated.

 

[Kerry Brown]

Try loading DOS into a virtual machine and run the program there.

http://www.microsoft.com/windows/virtualpc/default.mspx

Virtual PC is free. The hard part will be finding your old DOS disks to
install it.

 

[Malke]

This is one of those thinks that just annoys the heck out of me...

I have an old DOS database app, RBase, which I haul out once a year when
we
do inventory of a medium-sized manufacturing facility. Sure, it's old,
but I have extensive database scripts written for it and it gets the job
done
nicely. For its once a year usage, I have seen little reason to dump it.

Here's the problem: The app runs perfectly in a DOS window on my home PC's
- both desktops and notebook - but will not run on two of the office PC's
which I have tried it on. All of the PC's are similarly configured with
XP Pro/SP2 (and all available updates), all have fast P4 processors (>2
GHz) and large NTFS drives, the desktops have 1GB ram, 512MB in the
notebook. All have identical %systemroot%\System32\Autoexec.NT and
Config.SYS files. The NTVDM related files (ntvdm.exe, ntio.sys, ntdos.sys)
which I have
reviewed appear to be identical as well. The app's properties (Memory,
Screen, Compatibility, etc) are configured identically on each of the
systems.

On the office PC's, trying to run the main executable (RBase.exe) within a
"Command" window crashes with results similar to those described in
http://support.microsoft.com/kb/245184/en-us. On the other hand, if I
simply double-click the executable (or run it in a "Cmd" window) a DOS
window opens but the app never starts. The window remains black with a
white cursor which just sort of zips around within in somewhat diagonal
patterns (if the app were to start up, the window would have gone to a
white-on-blue text window drawn with the ASCII box drawing characters). I
eventually have to force the window closed by killing the app.

Both of the office PC's have no trouble running DOS apps in general; I can
open command windows and execute common commands without incident. I have
reviewed http://support.microsoft.com/kb/156687/en-us and
http://support.microsoft.com/kb/314106 but gotten nowhere.

FWIW, the office PC's are Dells which came preloaded with XP. The home
PC's are running retail copies of XP.

Any thoughts as to how to get this fixed would be greatly appreciated.

I have no idea why it doesn't work on the office machines. My suggestion to
you is to make it easier on yourself, especially since you only use this
app once a year, and install Virtual PC (or VMWare). Create a virtual
machine running DOS and you can then run your database without incident.

Malke

 

[Pegasus \(MVP\)]

This is one of those thinks that just annoys the heck out of me...

I have an old DOS database app, RBase, which I haul out once a year when we
do inventory of a medium-sized manufacturing facility. Sure, it's old, but
I have extensive database scripts written for it and it gets the job done
nicely. For its once a year usage, I have seen little reason to dump it.

Here's the problem: The app runs perfectly in a DOS window on my home PC's -
both desktops and notebook - but will not run on two of the office PC's
which I have tried it on. All of the PC's are similarly configured with XP
Pro/SP2 (and all available updates), all have fast P4 processors (>2 GHz)
and large NTFS drives, the desktops have 1GB ram, 512MB in the notebook.
All have identical %systemroot%\System32\Autoexec.NT and Config.SYS files.
The NTVDM related files (ntvdm.exe, ntio.sys, ntdos.sys) which I have
reviewed appear to be identical as well. The app's properties (Memory,
Screen, Compatibility, etc) are configured identically on each of the
systems.

On the office PC's, trying to run the main executable (RBase.exe) within a
"Command" window crashes with results similar to those described in
http://support.microsoft.com/kb/245184/en-us. On the other hand, if I
simply double-click the executable (or run it in a "Cmd" window) a DOS
window opens but the app never starts. The window remains black with a
white cursor which just sort of zips around within in somewhat diagonal
patterns (if the app were to start up, the window would have gone to a
white-on-blue text window drawn with the ASCII box drawing characters). I
eventually have to force the window closed by killing the app.

Both of the office PC's have no trouble running DOS apps in general; I can
open command windows and execute common commands without incident. I have
reviewed http://support.microsoft.com/kb/156687/en-us and
http://support.microsoft.com/kb/314106 but gotten nowhere.

FWIW, the office PC's are Dells which came preloaded with XP. The home PC's
are running retail copies of XP.

Any thoughts as to how to get this fixed would be greatly appreciated.

If Kerry's suggestion of a Virtual PC does not solve your problem then
here is a permanent way to resolve it. It is independent of any current
and future OS.
1. Get yourself a second hand hard disk. 2 or 4 GBytes will do very
nicely. You can probably get it for free, perhaps out of a retired PC.
2. Install it as a slave disk in your office PC.
3. Create & format a FAT32 partition on it.
4. Copy your application and its data files there.
5. Boot the machine with a Win98 boot disk from www.bootdisk.com.

You can now run your application on the old disk. To automate the
launching process, tweak a:\autoexec.bat to suit your requirements.

 

[Carmine Castiglia]

Try loading DOS into a virtual machine and run the program there.

http://www.microsoft.com/windows/virtualpc/default.mspx

Virtual PC is free. The hard part will be finding your old DOS disks to
install it.

I will probably give the Virtual PC route a try. No problem finding the DOS
disks; I have a copy of 6.0 on the shelf directly behind me right now and
I'm pretty certain I saw 6.22 (?) in a storeroom at the office recently.
Heck, I have a copies of DOS 5.0, Windows/386, Windows 1.0, and Windows 3.1
too!

FWIW, the thing that really gets to me is that I can't find anything
significantly different between the PC's which "work" and those that don't.
The home PC I am on right now (one of the ones that runs the app) has a 200
GB single-partition drive formatted NTFS; the office PCs that won't run the
app have 80 GB single-partition NTFS drives. As mentioned before, all of
the critical files seem to be the same version and byte-count; the creation
dates differ I think only because of the retail XP install CD's vs. the Dell
install CD's. I have checked things like anti-virus, firewall, etc.

The app (I still have the installation and user manuals) does not require
any special install other than a "FILES=20" (or more) statement in
Config.SYS/Config.NT and that's covered. On the home PC's, I can simply
copy the entire installation folder to a new folder, change to that folder,
double-click RBase.exe and it runs fine. If I take that exact same folder,
copy it to one of the office PC's and try to run it, it bombs as previously
described.

And, I didn't mention this earlier but the dbm includes a couple of database
utilities which are run as separate DOS apps. These apps run fine on all of
the PCs, both home and office. It is only the main executable, RBase.exe,
which fails on the office PCs.

 

[Kerry Brown]

I will probably give the Virtual PC route a try. No problem finding the
DOS disks; I have a copy of 6.0 on the shelf directly behind me right now
and I'm pretty certain I saw 6.22 (?) in a storeroom at the office
recently. Heck, I have a copies of DOS 5.0, Windows/386, Windows 1.0, and
Windows 3.1 too!

FWIW, the thing that really gets to me is that I can't find anything
significantly different between the PC's which "work" and those that
don't. The home PC I am on right now (one of the ones that runs the app)
has a 200 GB single-partition drive formatted NTFS; the office PCs that
won't run the app have 80 GB single-partition NTFS drives. As mentioned
before, all of the critical files seem to be the same version and
byte-count; the creation dates differ I think only because of the retail
XP install CD's vs. the Dell install CD's. I have checked things like
anti-virus, firewall, etc.

The app (I still have the installation and user manuals) does not require
any special install other than a "FILES=20" (or more) statement in
Config.SYS/Config.NT and that's covered. On the home PC's, I can simply
copy the entire installation folder to a new folder, change to that
folder, double-click RBase.exe and it runs fine. If I take that exact
same folder, copy it to one of the office PC's and try to run it, it bombs
as previously described.

And, I didn't mention this earlier but the dbm includes a couple of
database utilities which are run as separate DOS apps. These apps run
fine on all of the PCs, both home and office. It is only the main
executable, RBase.exe, which fails on the office PCs.

Trying to figure out an old DOS app doesn't work is an exercise in
frustration. Since I started using virtual machines those frustrations have
gone away. I actually like the beta of VPC 2007 much better than VPC 2004
but as you're using the DOS app for a business I wouldn't recommend using a
beta product.

 

[Bruce Chambers]

This is one of those thinks that just annoys the heck out of me...

I have an old DOS database app, RBase, which I haul out once a year when we
do inventory of a medium-sized manufacturing facility. Sure, it's old, but
I have extensive database scripts written for it and it gets the job done
nicely. For its once a year usage, I have seen little reason to dump it.

Here's the problem: The app runs perfectly in a DOS window on my home PC's -
both desktops and notebook - but will not run on two of the office PC's
which I have tried it on. All of the PC's are similarly configured with XP
Pro/SP2 (and all available updates), all have fast P4 processors (>2 GHz)
and large NTFS drives, the desktops have 1GB ram, 512MB in the notebook.
All have identical %systemroot%\System32\Autoexec.NT and Config.SYS files.
The NTVDM related files (ntvdm.exe, ntio.sys, ntdos.sys) which I have
reviewed appear to be identical as well. The app's properties (Memory,
Screen, Compatibility, etc) are configured identically on each of the
systems.

On the office PC's, trying to run the main executable (RBase.exe) within a
"Command" window crashes with results similar to those described in
http://support.microsoft.com/kb/245184/en-us. On the other hand, if I
simply double-click the executable (or run it in a "Cmd" window) a DOS
window opens but the app never starts. The window remains black with a
white cursor which just sort of zips around within in somewhat diagonal
patterns (if the app were to start up, the window would have gone to a
white-on-blue text window drawn with the ASCII box drawing characters). I
eventually have to force the window closed by killing the app.

Both of the office PC's have no trouble running DOS apps in general; I can
open command windows and execute common commands without incident. I have
reviewed http://support.microsoft.com/kb/156687/en-us and
http://support.microsoft.com/kb/314106 but gotten nowhere.

FWIW, the office PC's are Dells which came preloaded with XP. The home PC's
are running retail copies of XP.

Any thoughts as to how to get this fixed would be greatly appreciated.

Do the office machines operate under tighter security policies than
your home machines? Do you operate your home machines while logged in
using an account with administrative privileges, but have less elevated
privileges on the office machines? I've seen a lot of legacy
applications (including DOS-based) that suddenly "choke" when asked to
run on a more secure OS, simply because they were originally coded to
write to what are now protected system folders or files under WinXP.

You may experience some problems if the software was designed for
Win9x/Me, or if it was intended for WinNT/2K/XP, but was improperly
designed. Quite simply, the application doesn't "know" how to handle
individual user profiles with differing security permissions levels, or
the application is designed to make to make changes to "off-limits"
sections of the Windows registry or protected Windows system folders.

For example, saved data are often stored in a sub-folder under the
application's folder within C:\Program Files - a place where no
inexperienced or limited user should ever have write permissions.

It may even be that the software requires "write" access to parts
of the registry or protected systems folders/files that are not normally
accessible to regular users. (This *won't* occur if the application is
properly written.) If this does prove to be the case, however, you're
often left with three options: Either grant the necessary users
appropriate higher access privileges (either as Power Users or local
administrators), explicitly grant normal users elevated privileges to
the affected folders and/or part(s) or the registry, or replace the
application with one that was properly designed specifically for
WinNT/2K/XP.

Some Programs Do Not Work If You Log On from Limited Account
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q307091

Additionally, here are a couple of tips suggested, in a reply to a
different post, by MS-MVP Kent W. England:

"If your game or application works with admin accounts, but not with
limited accounts, you can fix it to allow limited users to access the
program files folder with "change" capability rather than "read" which
is the default.

C:\>cacls "Program Files\appfolder" /e /t /p users:c

where "appfolder" is the folder where the application is installed.

If you wish to undo these changes, then run

C:\>cacls "Program Files\appfolder" /e /t /p users:r

If you still have a problem with running the program or saving settings
on limited accounts, you may need to change permissions on the registry
keys. Run regedit.exe and go to HKLM\Software\vendor\app, where
"vendor\app" is the key that the software vendor used for your specific
program. Change the permissions on this key to allow Users full control."


--

Bruce Chambers

Help us help you:



They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -Benjamin Franklin

Many people would rather die than think; in fact, most do. -Bertrand Russell