🚀 go-pugleaf

Harry Chickpea <hchickpeaREMOVEME@hotmail.com> wrote
in message news:404a9c46.275708979@News.Individual.NET...
> Rod Speed <rod_speed@yahoo.com> wrote
>> Fritz Oppliger <fritzo_two_@direcway.com> wrote

>>> What is the magic needed to make qbasic
>>> talk to the parallel port on WinXP  ?

>> http://www.lvr.com/parport.htm

>>> (how did Microsoft manage to break THAT?)

>> By not allowing apps to do anything
>> they like to the hardware directly.

>> What any solid OS does.

> Uhh, make that any solid _multi-tasking_ OS.

Nope, because all OSs are multitasking now.

> The requirement isn't there in simple
> dos sytems and embedded controllers.

Those aint OSs.

> The real issue is more one of changing standards than direct control.

Nope. Any OS is about device control.

> MS _could_ have included ways for transparent control through
> the OS that still protected the OS, but it was simpler, cheaper,
> and in their financial best interest not to do so.

Its completely routine to do the job properly, with a device driver.

> MS has been trying to kill off DOS apps and force users
> into MS apps or Visual Studio designed apps for years.

Irrelevant to that question of direct control of hardware from qbasic.

> Some of the changes of standards are subtle and I
> wonder if they are designed to trip up older programs.

Mindless conspiracy theory.

Its actually just another example of it not being
practical to allow for all the obscenitys that
some get up to with direct control of hardware.

The problem is that doing it the right way is way
outside what the dinosaurs who insist on using
qbasic for direct hardware control can handle.

> Killing off support for LPRINT was an obvious way that
> basic programs were affected in the port over to NTVDM,
> but I've also found that copying a file to the parallel port
> using the copy command can be a problem as well.

Hardly surprising given that that sort of command line stuff is
way past its useby date too. Hardly surprising that that stuff has
a few quirks remaining when its not widely used at all anymore.

> In the past, I've been able to print null strings to send a LF CR
> to printers.  Now, I find that unless there is another character
> (such as a space) seperating each instance of LF CR, XP
> will sometimes (but not always) return a device fault error.

Hardly surprising that silly kludges like that can bite.

> I submit that this is either intentional
> to encourage use of the print manager

Mindless conspiracy theory.

> or an error in the OS that is unprofessional and unworthy of any OS.

No one is holding a gun to your head and forcing
you to use any OS that you dont approve of.

> I won't even go into the issues that can occur when running a
> DOS based app in full screen mode instead of windowed mode.

You're always welcome to cripple along on a real DOS machine.

The reason you dont should be obvious.

> One of the most powerful aspects of DOS was that each
> instruction was minimally affected by a blanketing layer of
> OS code that was subject to capricious change.

See above.

> When the OS operates as a middle manager between
> the low level commands and programs, any program
> becomes subject to OS management errors as well
> as any shortcomings of its own.   MS banks on this.

No one is holding a gun to your head and forcing
you to use any OS that you dont approve of.

You one of those into S&M ?