mouse problem in qbasic

[billford]

Whenever I go into a qbasic program my mouse pointer starts jumping around and I have no control over it. someone has suggested that maybe I have an old version of qbasic. I am currently using windows xp and have an amd 3200+ processer. any suggestions

[earlofqb]

Ok. First off, do you have a dual-core processor? What about hyperthreading? See 3rd paragraph if you do.

Second, try running QBasic in compatibility mode for Windows 95. Just right-click the icon and select Properties. Then go to the Compatibility tab, and check the "run this program in compatibility mode" and select Windows 95 (or 98/ME if you prefer) from the drop down box. Click apply and Ok, then run it. Test this setup, and if it doesn't work, try checking the "run in 256 colours" box and maybe the "turn off advanced text services for this program" box. Then apply and run the program.

Now, the thing about dual-core processors is that they often have conflicts with non-dual core programs (99% of programs nowadays). You have to select a specific core for the program to run on (otherwise it'll try to run on both and it'll go out of sync). Hyperthreading sometimes does this, especially for old programs. I have yet to figure out why, only that certain programs just die when hyperthreading is enabled (even though the OS is supposed to do this transparently).

So, if you have a dual-core or hyperthreaded processor, set QB for a specific core and disable hyperthreading for it (if necessary).

Now, as far as the actual mouse goes, I'm going to presume that your mouse only does this with QBasic and nothing else. If this is true, then there's nothing wrong with the mouse, and we can move on. If not, try reinstalling the driver or maybe even updating it (certain wireless and optical mice provide driver updates on rare occasions).

There's no such thing as a "new version" of QBasic. They're all old DOS programs, and the above tips tend to fix most of the problems. If not, just download a new copy off the Internet (don't worry, you should still have your programs afterwards (I can't vouch for any automated install programs you might find online. So, just in case, backup your programs before getting a "new" copy). Just make a folder called "backup" and move any .bas files there. Then move them back after installation.

Note, this shouldn't be necessary, but you never know. I once found a brand new auto-extractor for an old DOS game that would've overwritten everything if I had something more than a text file in the directory. Better safe than sorry.

[Mikrondel]

This is extremely weird behaviour that I've only ever seen joke programs or unusual viruses cause.

My first guess would be that NTVDM's Virtual Mouse Driver is somehow corrupt; in this case the behaviour would occur in any mouse-using DOS program. (NTVDM being Windows NT/2000/XP's DOS emulator in which all DOS programs run)

Also, if you're using a USB mouse, there's a very low chance that the mouse driver is being kind of weird about it. But I've never seen a problem with USB mice under NTVDM before.

Then of course, while very unlikely, QB could be corrupt in which case you would of course need to get it again, as earl suggested.

Find another DOS program that uses the mouse (like EDIT - go to Start->Run and type EDIT) and see if the problem also occurs there (Press Alt-Enter to switch between Full-Screen and Windowed mode). If it does, it's clearly an NTVDM problem.


Anyway; my suggestion would be to get DOSBOX off the internet and see if the problem also occurs when running QB in that. (DOSBOX is a little tricky to get to work; ask us if you need help)

earlofqb said:

try running QBasic in compatibility mode for Windows 95. Just right-click the icon and select Properties. Then go to the Compatibility tab, and check the "run this program in compatibility mode" and select Windows 95 (or 98/ME if you prefer) from the drop down box. Click apply and Ok, then run it. Test this setup, and if it doesn't work, try checking the "run in 256 colours" box and maybe the "turn off advanced text services for this program" box. Then apply and run the program.

I doubt that would help - but there's no harm trying.

earlofqb said:

Now, the thing about dual-core processors is that they often have conflicts with non-dual core programs

No such thing as a non-dual-core program. At any particular time. programs either have one thread, in which case they run on no more than one core (and other cores often service interrupts) or they have more than one thread, in which they run on 0 or more cores.

As far as I can conceive, the only conceivable problem that can result from this is if a driver is not thread safe. But that usually means that all programs are affected.

earlofqb said:

You have to select a specific core for the program to run on (otherwise it'll try to run on both and it'll go out of sync). Hyperthreading sometimes does this, especially for old programs.

I won't believe it till I see it. I have never seen a single-threaded program running on more than one (virtual) processor; that flies against all I know about sheduling. Doesn't happen. Can't. The results would be far too catastrophic.

earlofqb said:

I have yet to figure out why, only that certain programs just die when hyperthreading is enabled (even though the OS is supposed to do this transparently).

Indeed. Something else must be the problem. I'd guess that the programs themselves are multithreaded and buggily so. I'd like to know more about this problem.

earlofqb said:

There's no such thing as a "new version" of QBasic.

Yep. Whoever made that suggestion is probably not the best place to find computing advice


However, earl, you are incorrect. There is a new version of QBasic. Or there will be. I'm making it (along with a few others). For Windows/Linux/Unix. More info later.

[earlofqb]

Mikrondel, have you ever played a game called "Red Faction" for the PC? It is fairly notorious in its community for breaking constantly when a duel core or hyperthreaded processor is used. While normally I'd agree with you, I've seen countless people complain about the game "breaking" under hyperthreading (most common) or duel core (less common, as not as many have it, but still a possible issue as multiple people have complained about it).

Like you said, it'd have to be in the game itself, and 9/10 times I'd agree with you on that. But thanks to this (reoccurring) problem, I've learned that some things just happen whether or not it should logically happen (like me using VB.NET instead of a real language). I can't explain it, the company that made the game couldn't explain it (before they cut off all contact), and it's one of those mysteries of life (like why Linux hasn't surpassed Windows yet...).

Nice catch on the virus/spyware thing. I based my answer off the assumption that his version of QB was a true version and not some Trojan; and that his NTVDM worked properly. After all these years programming, repairing computers, and generally troubleshooting, it's rather sad I still make these kind of presumptions.

So, how do you plan to go about making a new version of QBasic, and will it be compatible with the pre-existing version? (Countless quesitons arise here, but I won't hijack a thread just to ask you the many questions I have. I'll wait for its completion).

[Mikrondel]

Sorry to hijack, but can't resist. By "New version of QBasic" I don't mean "programming language based on QB" - there are lots of those. I mean - NEW VERSION - OF QB. Practically no changes to the language; we intend for EVERY old QB program that does not involve asm, or interrupts, or POKEs, or OUTs, or very obscure and undocumented hacks, to work. Many programs that DO use common asm/interrupts/POKE/OUTs/hacks will also work. Made with C++ and SDL for the time being, and that's all I'll say.

And - I didn't say multicore/hyperthreading can't cause problems. I just said that a single-threaded program will NEVER be run on two cores at once. But there could be a completely different problem being caused by multicore/hyperthreading.

I'd guess that Red Faction (never play'd it) uses more than one thread (perhaps not even its own; maybe some graphics library thread or something...) and somehow it's not thread safe - could be something like the CPU cache being used by one thread and not the other.