Qbasic in Windows XP 2

[qbasicking]

I have Windows XP, when I open Qbasic it comes up as a window; a very small window, I can hardly see what I am doing. When I maximize it it doesn't make much difference, it is still too small to read.
How do I make it take up the entire screen? Do I have to change the PIF file?

 

[clockrep]

I don't know if it will work in XP, but ALT + ENTER works in Win98.

 

[dilettante]

You can use Alt-Enter, or modify the PIF.

But I have found that under Windows XP, QBasic is much more stable if you run it in

command.com

(the 16-bit command-line shell) than in

cmd.exe

(the default, 32-bit shell).

This is doubly true for VB for DOS which I messed with a little bit.

Just edit the shortcut (PIF) so the "Cmd line" field on the "Program" tab of the shortcut properties says something like:

C:\WINDOWS\system32\command.com /c qbasic.exe

Hope this helps!

 

[Guest_imported]

1 Click with the right mouse button on the Qbasic executable.
2 choose 'properties'.
3 choose 'screen' bar.
4 coose 'full-screen' option.
5 click 'ok'.
6 run qbasic!

 

[qbasicking]

Thank you, since writing this post I have figured that out though. lol. sorry

 

[logiclrd]

You can also run it in a window with a different font. Click once on the control menu (the icon at the left end of the titlebar), and select 'Properties' from the menu that pops up. A property page dialog should appear. Under the second tab in the dialog, "Font", you should be able to change the size of the font. When you click 'Ok', the entire window will resize to match.

 

[Guest_imported]

qbasicking is lucky!! i have the same problem, but right clicking and changing "properties" to "full screen" would cause a screen blackout,except some vertical dotted lines, next time I run qbasic. What shall i do? One thing more vexing is that command "screen 2" etc will also lead to a screen black out. But that's important to me. The Qbasic app was programed by myself and took me years' of spare time. Hard to think it doesn't run in XP... Somebody help me.

 

[logiclrd]

Sounds like bad video drivers. I recommend you search your manufacturer's web site for updated ones. If they have none, then I recommend you invest in a more mainstream video card. In particular, anything by NVIDIA uses the same drivers, and thus should work just fine. Also, in general, ATI has been known to have a lot of driver problems, even with recent cards. Starting with the R300, they're planning to go to a unified driver model like NVIDIA (but then, they said that about the R200, too). But of course, what do I really know -- it could be an incompatibility with your motherboard. The most important thing to recognize is that it is probably only your system that is failing to run the program, and not all systems running XP (I can use SCREEN 2 just fine on my XP system).

 

[Guest_imported]

Thank you logiclrd. I guess you are right. How did you know that I'm using an ATI card? In fact the graphic adaptor in my computer is ATI radeon 7500. It could be unfair to API to until I make sure...Hope we havn't wronged a good boy.

 

[SteveBzzz]

Yes....

Ahhhh, the good old days of QB. I have QB4.5, and I still use it today to whip up quick programs. I remember buying that program, and it came with like 2 200 page manuals. Now, all you get is a pamplet.

Enough rambling...

I too have been experimenting with running QB on XP and have found out two things. First, your machine has to emulate a DOS machine. Because of this, it comsumes huge amounts of system resources...almost 100% on mine. As I type, the screen display takes a second to catch up with my typing. Does everyone else experience this?

Also, I forgot the other one. But does anyone know how to access the advanced compatability settings in WinXP. Not the compatability wizard, but there is a command that gives you access to around 50 different parameters that you can tweak for your old programs to run in XP.

Thanks,

Steve

 

[logiclrd]

I believe the NTVDM makes use of profiling to determine when the DOS program is in an input loop. When this works, it allows it to suspend the program when it is doing nothing but waiting for input (in much the same way that a Windows program becomes suspended between keystrokes). However, the successfulness of this profiling is system-dependent. On my system, it works perfectly (I am using a Dell with a P3-1000 processor and 512 MB of RAM), and QB & QB programs do not hog CPU time when they aren't actually processing. Even loops sitting on [tt]INKEY$[/tt] do not misbehave.

One thing that it could be is that the profiling pattern is different for AMD processors. Other than that, it's virtually impossible to determine exactly what Microsoft is doing inside such an insanely complex design as the NTVDM. In general, if you haven't explicitly configured the NTVDM to use 100% CPU time even during input loops, then the fact that it is doing so means that it is not able to detect the input loops. Ah well, not much you can do, really

By the way, I am slowly working on a clone of QB written in platform-independent C. The front-end with which it will distribute initially will be Win32. The design allows different front-ends to be written and integrated with minimal difficulty. The project seems to go in little bursts, so I don't know if I'm ever going to actually finish it, but if I do, I will post a message to this message board among others

 

[Nyaj2k1]

Ummmm... Firstly, in order for a DOS prompt to take up 100% system resources in XP, I imagine your computer is quite slow. I would guess less then 500mhz P2.

Also, note that *some* computers run QB just fine. Mine for example, has no trouble whatsoever running QB under XP.

 

[logiclrd]

Apart from ragging on the processor speed issue (which, by the way, is not valid), isn't that pretty much what I said?

The reason that CPU speed does not matter and that it can use near 100% CPU time on any processor is the nature of a DOS-based input loop.

In Windows, the operating system sends your program a message when input arrives. In DOS, the program must repeatedly poll for it. Consider the following loop:
[tt]
DO
a$ = INKEY$
LOOP UNTIL LEN(a$)
[/tt]
This loop will spin until it gets a key. If you use [tt]INPUT$()[/tt] instead, the spin loop is implicit but still present: QB spins on your behalf. Spinning is a term that refers to a process using as much CPU time as possible. Usually, it is used for very short amounts of time in high-performance real-time multi-threaded and multi-processing applications to acquire locks on objects for which the locks last a very short amount of time. In other words, if the thread on processor one has a lock on object X, and the thread on processor two wants a lock on object X, the thread on processor two will spin, repeatedly attempting to get the lock. Typically, it will not spin for more than 200 or 300 iterations, the idea being that after that many clock cycles, the thread on processor one will have finished what it was doing and relinquished the lock.

DOS programs, however, spin for astronomically larger amounts of time when waiting for input. They go into a loop that looks basically like this:
[tt]
1. Is there input?
No? Go to 1
Yes? Proceed to process it.
[/tt]
This kind of spin loop works great in DOS, but when you're trying to emulate DOS in a multitasking environment, your emulator is forced to do what the spinloop says. That is, unless your emulator can detect the spinloop and wait for input the event-based way (i.e., wait for Windows to notify it of more input).

The NTVDM is fairly good at detecting input spinloops in DOS applications, but it is not perfect, and it does not work on all systems. It has nothing to do with processor speed. If it does not detect the spinloop, then it will use nearly 100% CPU time (unless you throttle it by setting its priority to Low, in which case it will become absurdly unresponsive and impossible to work with).

 

[SteveBzzz]

Hmmmm,

Well, I have a P4 2.2GHZ, 512MB of ram, so that's not a problem. Also, I just want to make sure that we are talking about the same loop. We're talking about the "loop" of the OS waiting for keyboard input, NOT A LOOP IN BASIC, as in the Do Loop above right? Do you think that Windows XP uses a Hardware Interrupt to process keystrokes, or is it polling?

Funny thing is, the actual QB program that I wrote runs at normal speed, right from the editor, (not compiled). For example, my program does a loop 10,000 times performing some mildly intensive calculations, and it only took a FEW SECONDS.

However, I can not have QB open, and run the Windows Media Player running for example. Also, system resources are at 100% as long as I have QB open, whether I am running a QB program, or just sitting in the editor.

If I just create a DOS Window and just start typing at the C:\ prompt, the letters on the screen still lag behind my actual typing by about 1/4 of a second.

Hmmm, I tried another DOS program from 1984, seems to work fine. Still a lag between keystrokes, but nowhere near 100% usage. I am able to run a media file in Windows media player at the same time that the DOS program is running.

I set the Idle sensativity of QB to high, and It seems to run better, about 50% CPU usage. Also, If I look at the processes running under the Cntl+Alt+Del menu, I see that the only allocation of resources is to the dos window(NTVDM), and the "System Idle Process" it's 50/50. But since the cpu usage is now about 50%, each process is using 25% of the SYSTEM resources.

Also, does anybody know how to access the advanced compatability settings for running older programs? I'm not talking about compatability wizard, this function lets you tweak about 50 different parameters. I did it before, but I just forgot how.

?????????????

Steve

 

[SteveBzzz]

Hmmm,

Just when I thought it was over, I tried dilettante's suggestion of using "C:\WINDOWS\system32\command.com /c qbasic.exe" and it seems to work better. Still some lag, but I can run media player while qb is open.

Also, if you do it that way, you get "microsoft windows dos" instead of Windows XP DOS"

More to come...

STEVE

 

[Guest_imported]

I am running windows XP on a Pentium 2 processor. Yea I know that is a bad idea, but hey gotta work with what you've got. But here's the problem. When I run QBasic the CPU usage goes up to 100% and stays there and the mouse lags. Any idea on what I should do?

 

[SteveBzzz]

Griff,

First, why are you running XP? Second, I have the exact same problem. Read the thread from Sept 15 on. It's working a little bit better for me now.

I love Qbasic,

Steve

 

[qbasicking]

The CPU usage goes up to 100% whenever you run ANY dos program, it's unavoidable

 

[logiclrd]

I would say that it is difficult to avoid. It is possible to detect most input spin loops, but it is very tricky, especially to do it with good performance. The NTVDM *does* try to a certain extent, but it places more emphasis on compatibility than performance.

 

[rigel]

GUI-Window-graphics in QuickBasic
Hallo
since it use I QuickBASIC below WinXP, some signs of window-graphics (corners, lines and so forth)
are announced correctly no more.
Property already the code page changed (437> 850), without success.
Is there aid?

Greeting Klaus