you are correct. The only workaround (aside from coding those switches)
is booting a diskimage of a version of dos inside dosbox. That gives you acces to that diskimages commandline interpreter.
(see the boot command for the syntax)

Thanks for the reply and I'll keep that Disk image info in mind.

This morning I'm finding some hopeful news on how to change the Video settings in Vista to support full-screen console programs. These bleeping wide screen notebooks have such low vertical height that it makes most windowed console applications look idiotic in Vista. 'tupid MicroSoft! (I miss the days when Windows ran on top of DOS instead of the other way around.) But I digress...

By the way, does DOSBox support anything like the START statement in DOS so another program can be started in an application without exiting the program? A batch file could be launced if so that could do the directory work and create a file, which could later be read withing the program.

Again, thanks for your help.

Pete

Well int21/4b starts programs.

Never thought of using interrupts to replace the START command. I'll have to get with a friend who is good at ASM. QB uses CALL INTURRUPT and could accept variables to use INTURRUPT 21 to start a program. That might just work, as it would eliminate the need for the SHELL statement.

It will take some experimenting.

Thanks for the idea,

Pete

For QuickBasic you should stick to the commands/tools it provides,
int21/4b might be tricky to get to work from within a basic program
due to memory/environment handling.
Best thing to do is execute (how ever, be it a basic-internal thing or
int21/4b) something like "$COMSPEC /C prog.exe" where comspec is
that environment variable pointing to command.com

I have some large apps for QB; so, I completely agree, memory would probably be an issue with CALL INTERRUPT.

I'll look into your other suggestion.

Also, one final question. Since I'm fortunate enough to have the DOSBox author replying to this thread:

-----------------------------------------------------------------------------------
Will you please state if DOSBox can run 16-bit apps in full screen in Vista or not? I will post a reply to your response to the FAQ of the QBasic forum. We all love your product over there by the way. One of our best graphic artists uses DOSBox on his 64-bit XP to get his QB programs to work. Great product, as I'm sure you're aware of.
-----------------------------------------------------------------------------------

I have read posts at other forums that go both ways. Some same DOSBox cannot your Basic programs full-screen on Vista, others say you can. Maybe it's just the version number or a lot of misinformation.

The main reason I'm asking is that we will be getting more people coming to the QB forum asking if they can run QB graphic programs FULL-SCREEN in Vista. I know Vista will not support a full screen console app. It won't run PowerBasic 32-bit console programs full-screen or FreeBasic 32-bit console programs full-screen. The video driver was simply made not to offer a full-screen console mode, period.

The only other workarounds I know of are installing Virtual Machine, which actually places a bitmap to the screen to fool the display (works on text programs full-screen, too.) or adjusting the video graphics display and probably installing an XP video driver.

Personally, I've made QB programs for my office for years. They run everything from appointments, to ledgers, even word-processing applications. Around 5MB of source code in all. I should have spent some more time learning C but Basic just got the job done so much faster. Anyway, I'm very glad to see you were able to develop a way to keep older programs functioning.

Thanks,

Pete

Well dosbox should run on Vista quite fine (either 0.70 or 0.71...)
and fullscreen works, too. So as long as the programs you want to
run are 16bit or 32bit dos apps it should work.
Don't know about power basic, but QuickBasic and QBX work fine
under dosbox.

DOSBox offers a fairly compatible environment for any DOS game. This often also means that other DOS applications work, especially when you are booting a hard disk image. There is no guarantee, however, if you are using hardware-related tricks or exotic DOS interrupts.

DOSBox includes a very versatile video hardware emulation, which not only means anything that is displayed can be displayed in full screen, but also that a variety of extra effects are possible that are not available in native full screen modes. DOSBox is, however, a full machine emulation, so it works a lot like the virtual machines you mention. It's advantage over other emulators/VMs is the focus on great DOS compatibility, which probably surpasses any other emulation in existence.

Thanks for the extra info guys. I've been away for awhile working to install DOSBox in a Vista Home Premium laptop. It took me awhile to figure out that when a drive is mounted to DOSBox, I cannot get to a lother folders outside of the mounted folder even if I use an absolute pathway. What I did to fix that was to remount DOSBox to the root drive, then cd to my program directory and then executed the program. No problems accessing pathways from that setup as now I'm running from the root drive.

Well as far as Vista goes, you're right that it will run QuickBasic programs fukk-screen but Vista is a bit of a bugger. It crashed on the first full-screen attempt. I read a few other posts that stated this as well. I ran it again and it stayed full-screen but after about 1-second, the screen became quickly and nearly completely faded you could hardly see anything. If I advanced the program, the brightness came back, sometimes. On some runs this problem never happened, on otehrs, it was tougher to get the display bright again. it’s very unpredictable.

As far as program function, the only MAJOR problem I noted was the mouse vanishes after the first click! It is there and functional, but you cannot see it. It is as if the "Hide mouse" function that was available in XP gets automatically kicked in. I consider this a major problem but maybe it has been reported and has a fix.

Any ideas about what went wrong with the screen darkening display or mouse in hiding would be appreciated. By the way, the only way to get the mouse to reappear for another single use click was to use ctrl + Esc.

Thanks,

Pete

I just checked the README file and tried ctrl + f10 on my 98 and Vista. It brought the mouse arrow back to the screen each time but again, one click, and it was gone. The black arrow that appears doesn't seem to work, but after it vanishes, I can move the hidden mouse around a bit and eventually trigger an event. This is all very strange,

I use CALL INTERRUPT for QuickBasic Mouse routines. I might try a CALL ABSOLUTE routine tomorrow.

Pete

play with the autolock varaible.

A good idea would be to use the initmouse and SHOW mouse commands.
Otherwise you of course don't see any mouse cursor.

I tried various mouse sensitivity settings from 0 to 200. No change. I set the value to "false" with the default setting of "100" and no change.

BTW - These apps do work perfectly in DOS and in NTVDM. Seeing the mouse in a window or full screen was never a problem before. My code is written to initiate the mouse and show and hide it at the appropriate times. However, these applications do nearly max out QB memory and use a lot of screen switching and PCOPY. I have noticed that a few of my smaller apps. with the same mouse library added work just fine. My hunch is that DOSBox needs more memory allocated to run them. I also noticed that one large app. caused DOSBox to freeze up and my system to crash when it tried to RUN another large app. from it. This again leads me to believe it is a memory issue and not a problem with the mouse sensitivity setting or the autolock-true option.

I might try fiddling a bit with the 'core' settings or if you have a recommendation to increase memory without pushing it into a crash, please let me know.

Thanks,

Pete

If the crash/mouse visibility does NOT happen under real dos, too
(and quickbasic stuff is picky there, too, especially with those int
calling libraries) then post the executables.
Don't know what mouse sensitivity should have to do with this.