Announcement

**Mark Baker** · 22 Dec 2003, 12:47 PM

Mike,

I see no one has bitten on this thread, I will have a go

Terminal Services passes alot of data via its interface (RDP protocol).
You will note that in XP, terminal services has been replaced by
Remote Desktops (to take advantage of W2K3), a kinda MMC snap in that is much
improved, however there is still alot of data to move ( I personally
find client improvements if the remote desktop is low res and color depth).
You did not say what kinda link there is, Dial up, dsl etc ... but
this will all affect how you see processes running on remote pc's.

The fact that is operates as "your boss" intended in your office
hints at a network type issue here, also you state late in the post
that "I have tried to replicate this problem on several of our office
machines, even running the program through a TS session and it performs
normally" suggests network problems.

Have you tried the remote desktop download from Microsoft for W2K instead ?
I have and it performs better than Terminal services ever did.

Also console mode apps do appear to be better via this type of interface ?
well 80x25 is a lot better to transmit than in depth color to transmit.

sorry if I have taken this the wrong way but just wanted to help out !

give us some more info and I can re evaluate

------------------
Regards

Mark Baker

[This message has been edited by Mark Baker (edited December 22, 2003).]

**Mark Baker** · 22 Dec 2003, 12:50 PM

maybe my answer is wasted, what the is a "COLO" machine,
I bin around for a long long time and have never heard of this type ??

please someone explain

------------------
Regards

Mark Baker

[This message has been edited by Mark Baker (edited December 22, 2003).]

**Mike Hansen** · 22 Dec 2003, 01:24 PM

Hi Mark,

Thanks for your reply...

When I say COLO machine I meant that it was one of our servers at our hosted facility. I will give the remote desktop a try and see if that improves performance any but I'm a little doubtful just because of the behavior I've seen so far with the problem.

When I connect via TS we are going over a 768k/768k DSL line we have here at our office, there is a VPN setup here and at the hosted facility. From what I can tell it really doesn't seem like TS is the culprit because we have run many other programs through TS and haven't experienced any performance issues quite like this.

Even if TS was the problem, it still doesn't quite explain why I see such a difference on CPU usage when running the program locally on a WIN2K box or on the server WIN2K box through a TS session. Since I'm in Seattle and the servers are located in Atlanta I can't go verify the performance problem locally on the box but I believe I would see the same thing. I may have a SA go and check for me if I get time.

------------------

**Mike Hansen** · 22 Dec 2003, 01:54 PM

Here is another update...

I tried using the remote desktop, while I think I may prefer this client to the TS client, I still got basically the same issues. The program now starts up a little faster, but the keystroke pausing is still there. I can type in a file name watch maybe 1-2 characters appear as they should then it just sits there. Meanwhile I can open up SQL, browse directories, do virtually anything else on the machine while I wait for the keystrokes I entered to catch up. This tells me that I'm not having a connection problem. The program is just sitting there waiting to do something even though it should have been echoing my keystrokes. This is why this issue is leading me to point toward a hardware issue even though it would normally seem unlikely.

------------------

**Herman Kieskamp** · 22 Dec 2003, 10:37 PM

Remote desktop and terminal servers are windowsprograms, that
cache's windows, ico's etc. A Dos program requires a screen send over
instead of cached windows controls movement send. You can test this to
partly overlay the dos window with another (windows)window on the remote
machine, let's say youre just able to type in and see the command. If that
speed up things, you know it's the dos-screen, together with the NT-VirtualDosManager.
You may wanna suppress output to screen, and instead use file input-output if possible!!
Or try rewriting it in a windows program.

Herman.

------------------
You gotta run, and don't loop back.

**Terry Fritts** · 23 Dec 2003, 02:00 AM

It doesn't sound exactly like a TermServ issue but then again I've seen TermServ
do strange things to a few programs. If I suspect its an issue I usually test by
getting on with VNC. http://www.realvnc.com/download.html

**Michael Mattias** · 23 Dec 2003, 06:30 AM

its only when running this or other old PowerBasic programs that the performance issue occurs

More likely, programs from a specific old PowerBASIC programmer.

Many of those old MS-DOS programs were written with the user input loop something like..

Code:

DO
  K$ = INKEY$
LOOP UNTIL LEN(K$)
(process keystroke here)

Nearways as I can tell, this particular coding technique sucks CPU time in the simulated MS-DOS provided by 32-bit Windows.

Not that i can think of any better way to code the DOS program, but this might be a contributing cause to poor performance.

MCM

[This message has been edited by Michael Mattias (edited December 23, 2003).]

**Mike Hansen** · 23 Dec 2003, 10:33 AM

Thanks for the tip Michael, from what I've seen of my boss' old PB code he usually doesn't write inputs like that but it is still possible in this case. I'll investigate the code and see what I can find out.

------------------

**Shawn Anderson** · 7 Jan 2004, 10:24 PM

have you tried tamedos? www.tamedos.com
free trialware download

------------------

**Stavros A Petridis** · 8 Jan 2004, 06:22 AM

Mike,
I had a similar problem with Win2k and XP when using PC AnyWhere and
DosBoxes.When i used the PC Anywhere with Win32 apps runing on the host PC all went ok,but as soon
as i run a Dos program the connection was becoming very-very-very .... very slow.
I solved the problem by setting the priority of the PC AnyWhere host modul to "Above Normal"
I think your problem is the same.The Dos program takes up most of the CPU priority and the
TS communication modul doesn't take much of the CPU's attention.

------------------
Byte Hunters of the World Unite.

**Mike Hansen** · 8 Jan 2004, 04:23 PM

Thanks for those extra ideas Shawn and Stavros, I will give them a try when I get a chance and let you know the results.

------------------

**Mike Hansen** · 8 Jan 2004, 06:28 PM

Looks like TAME is the best solution, I tried changing the priority of termserv.exe but you aren't allowed to change the priority because of "Access Denied". After installing the evaluation version of TAME the programs work normally, great little utility.

Thanks for everyones responses. My boss is happy we don't have to re-write lots of old PB programs into windows apps.

------------------

**Mike Luther** · 8 Jan 2004, 11:04 PM

Mike ...

For what this may be worth, who knows. You have just discovered both
one of the real problems of using PB for DOS in later and greater operating
systems, together with one of the most important little utilities which
can be acquired and used to sincerely help you for the future.

This is not just an issue with later and greater versions of WIN when
used with these programs, but can also show up big time in the IBM OS/2
operating system as well. And it is VERY far from dead and funded through
absolutely 12-31-2006 plus spoken-to in public toward by IBM actually as
far as the year 2019 now. There are just too many embedded system, mission
critical and hardware-related oriented issues which absolutely cannot be
addressed for many people in any operating system platform which goes
off and forgets the past. I have hardware, software and complete operations
running code all the way from 1974 to current date, including every single
bit of PB 3.5 code that has ever been created here .. and it will continue
to be supported, as far as I and a lot of others know as posted above.

That's important, particularly when by law you have to be able to support
things with no questions asked for seven, ten or more years in the future, or
face serious liability issues if you fail. And PB, for the real answer, as
a DOS application in these superb heritage operating system support issues,
simply is one of the best toolsets you could ever use for this stuff.

What you have just, apparently discovered, is that TAME introduces required
time slice releases in your much more recent multi-tasking operating system
which are simply not normally required in PB 3.5 for DOS as a single tasking
operating system! That is *NOT* a fault, really, in PB 3.5 for DOS, although
in a future release of it, it would very kind of the PB crew to consider making
available the tools to help us, which can be written.

For any future reference, the same general utility TAME330 also exists in the
OS/2 operating system world. It is a God-send for a lot more than just the
PB arena with the looped polling problems. It is paid-for utility and in
my standard arsenal of DOS tools here in OS/2 and has been for years now.

If you are sincere about re-writing the code to provide internal time slice
releasing, there a a series of ASM coded routines which are known and
documented in the forum here. They can be used to internally do the same
kind of thing that TAME does for you. But it takes some learning, and thinking
about all this to provide the general solution for source with which you
work. Different trace techniques in the ASM code can determine, at least up
to just before WIN-XP here, figuring out what operating system is in use,
and how to release time slices for it which eliminate the need for TAME which
you have discovered. I think if you do a forum search here you'll find most
if not all you need to know to learn this is right at hand.

I'll prolly get toasted at sunrise for making this suggestion, but I'm not
at all embarzado! If the issue of support resolves into an issue where you
simply have to stay in the DOS arena with PB, you might actually consider
even a brand new route to OS/2 to do this! ECS as a dedicated toolset for
intalling the brand new OS/2 MCP versions, totally supported even as we speak,
in some places, I think, can be found still for only about $75 now! Although
IBM makes it difficult for you to find how, frankly, the entire official IBM
total new MCP system at Fix Pack 4 now, with EVERYTHING in all the official
fixes, is only about USD$175 which includes a full year of upgrades and
even defect support, plus only USD$65 a year from then at this time! We'll
not dwell on defect support as the importance of it can make the cost vary
considerably, but the Usegroup support for this still C2 security mission
critical system is darned good.

I have servers which have not failed in FOUR years, nor lost one byte
of mission critical information under it.

You can even get host operating system capability for it under WIN of all
kinds, grin, plus both Citrix and VMware can absolutely fix the issue of
Host/Guest operations to support you. Given the CPU horsepower and memory
needed, I can frankly run WIN-XP or even two or three different WIN
operations under my own licensed Connectix Host operation under mission
critical OS/2. And also LINUX if I want to.

What you have stumbled on to, and solved, is your first real look at how
things have grown up in the world! Yes, you can move with PB tools direct
to the Brave New World. But if you have to run a whole machine shop of
NMC stuff or whatever, do some real investigation on how to cross work
with the tools which are really available to you. You may find that the
future does hold PB 3.5 for DOS upgrades for you. But it will be LINUX
and directly available too. Don't sell anything short in your search for
the light ..

It shines brightly for all use here; really it does! And PB with it
is mission critical as well, case closed, at least in my humble world.

------------------
Mike Luther
[email protected]

**Robert DeBolt** · 28 Oct 2004, 08:35 PM

Chuckle

I'll prolly get toasted at sunrise for making this suggestion, but I'm not
at all embarzado!

Does not "embarzado" mean "pregnant in Spanish?

------------------
Regards
----------------------
Robert DeBolt
mailto:[email protected][email protected]</A>

Announcement

Poor performance in WIN2K

Poor performance in WIN2K

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment