Pete's QBASIC Site

Can QB woks with the new computor, WIND 2000 XP?
Read somewhere basic programs were no more usable?

i never have had XP or 2OOO but i have been reading and posting in several quickbasics forums for a long time.
quickbasics can run and compile correctly in those systems, i am completely sure. those systems try to restrict the Ms-dos environment. it is neccessary to see the properties of the Ms-dos environment to give more expansion to the limitations that those systems put to the Ms-dos windows.
there is a file to modify the limitations, i can remember that the name of the file is NTVDM.

Programs doing "plain QB" work without a problem.

You will run into problems if you use game libraries that access SVGA modes, EMS memory and/or soundcard. Tweaking with hardware ports is not allowed at all.
There are workarounds to all of these problems but they require special settings or additional software thay may not exist in every computer.

If you need those additional features, you may want to look into FB. If not, QB will work like a charm in W2000 or XP.

I'm using Windows XP Professional and compile all my programs with QuickBasic 4.5. I think I have encountered a compatibility problem with the MSDOS under Windows XP.

A few weeks ago, I was writing a program that needed to know if a particular directory existed.
Let's call the directory \TEST.
I created this directory for testing.
The program issued this SHELL command:
SHELL "IF EXIST \TEST\NUL ECHO YES>ANSWER.FIL"

After running the program the file ANSWER.FIL never contained YES, it was only a zero-length-file.

However, if I executed the exact same command from the MSDOS command-line; that is,
IF EXIST \TEST\NUL ECHO YES>ANSWER.FIL
then the ANSWER.FIL contains YES.

I tried substituting the ECHO for a TYPE command of another file. I tried other directories and subdirectories. The results were all the same. The SHELL command in the program does not work, but the same command from the MSDOS command-line works fine.

Maybe it can't recognize the \NUL from a SHELL.

Is this really an incompatibility or am I doing something wrong?
*****

Hey guys,

I would greatly appreciate any comments/suggestions on the possible incompatibility described in my previous post.

Thanks.
*****

It's a well accepted truth that if your target platform is anything newer than windows 98, you do not want to use DOS as the base platform.

DOS support is poor, if there is even any support at all.

DOS is outdated and doesent take advantage of modern computers to an acceptable degree.

Moneo:
I tried your code in W2000 and I have the same problem.
It seems qb shell runs a somewhat crippled version of command com in NT-W2000-XP, I don't know why!

Antoni wrote:Moneo:
I tried your code in W2000 and I have the same problem.
It seems qb shell runs a somewhat crippled version of command com in NT-W2000-XP, I don't know why!

Thanks, Antoni. It's comforting to know that the problem is not just on my machine. As they say: "misery likes company."
*****

I tested on WinXP SP2 and have the same problem... the only solution I can think of is to test if the current OS is NT/2000/XP and, if so, prepend "cmd /c " to the command line. This seems to work correctly. I can't figure it out, either - apparently there is some alternate shell that is executed when using SHELL with an argument. Interestingly, using just SHELL without arguments seems to run the standard COMMAND.COM which acts as expected.

Or you could leave that "command /c" in every shell line. Probably it will not harm in W98

To make short what would be the code to start a recorded QBprogram on those XP devices?

DrV and Antoni,

The SHELL command in question is:
SHELL "IF EXIST \TEST\NUL ECHO YES>ANSWER.FIL"

I prefixed the SHELL line with "cmd /c" and it issued an error at runtime.

Prefixing with "command /c" like:
SHELL "command /c IF EXIST \TEST\NUL ECHO YES>ANSWER.FIL"
runs, but does not put YES into ANSWER.FIL.

I also tried doing a SHELL "command /c" first and then SHELL "IF EXIST..."
and that didn't work either.

Perhaps we do have an incompatibility.
*****

Can somebody tells me what code I must type to open QBASIC on a XP?

I've compiled and run programs using QuickBASIC v 3.0 on 8086, 286, 386, 486, Pentium I, II, and III computers running DOS 2.1, 3.x, 5, 6.0, and 6.2 plus Windows 3.1, 95, 98, NT 3.51, NT4.0, Windows 2000, and Windows XP with no compatibility issues found anywhere. But then, I don't do very complicated stuff, and no graphics.

"Shelling" to the command line from QB can work... but remember, each time you SHELL to the CMD line, it is a new instance (New ENVIRONMENT) all ENVIRONMENT variables are local to the session. Under NT/2000/XP/2003 each DOS BOX runs in a separate session. (Due to the fact it is a 16bit app.)

As long as all the work is done at once; writing to the file then leaving, then returning to read the file... all is well.

A common mistake would be to SHELL to change directories.
Then to SHELL and write a file (thinking it's in the new directory) - when a new session has started, and you are back at the original directory.

- Hope this clears up a few things.

UWLabs wrote:.....
A common mistake would be to SHELL to change directories.
Then to SHELL and write a file (thinking it's in the new directory) - when a new session has started, and you are back at the original directory.
.....

I'm running XP. In a QuickBasic compiled program running in my \moneo directory, I did a SHELL to change directory to \TEMP, and then SHELL to write to a file using redirection (SHELL "DIR >TEST.FIL")

The TEST.FIL was in the \TEMP directory, and the contents of the file was a directory listing of the \TEMP directory. When the program terminated it was positioned at the \TEMP directory.

The above results are contrary to what you said. However, my program was complied, perhaps your findings are for a QBasic program running interpreted. I don't have QBasic, so I can't test that.
*****