DOS applications on Windows2000 5

[Laurie321]

When I run DOS applications written in Clipper, the CPU jumps to 100% and sometimes crashes on computers running Windows2000. These are applications that I maintain at work and we need to keep them running.

I’ve read other threads that had this problem but I didn’t get enough information to solve my problem.

I’d appreciate any help.

 

[Elkari]

I found a reference to a software package called Virtual Machine under the Windows XP forum. You may want to visit www.vmware.com to check this out. The software is good for Windows 2000, NT4 and XP to set up virtual machines running different operating systems on the same computer.
With all the headaches that 2000, NT4 and XP are giving DOS apps, it might be easier to set up a virtual DOS machine to handle this.

 

[malysg]

Look for dosIdle.obj and include it in your link file. Then in your main program insert the line DosIdle() and be happy.

greetings, Gino Malys

 

[oldfart]

I have a fix for this, plus other useful hints for clipper on networks. e-mail me at pck@tokleyhiggs.freeserve.co.uk and I'll send you details and .lib files.

 

[Laurie321]

I found a fix that seems to work. I used Nanfor.lib and a fonction called FT_ONIDLE that drops the CPU when in idle.

I want to thank the people that responded and helped me.
Thank again.

Laurie321

 

[ProfReynolds]

Here is a solution that a friend gave me for NT and 2000 systems that works. Really! It does not solve the CPU utilization problem on 98 and Me, but you may find (as I did) that your 98/Me fix is compatible with this and can be installed along with this fix.

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

I am not sure if this will help, but I created a work around a couple of years ago for the getsys and inkey() that has stayed in our programs since which does not use the third party libraries. I wrote a simple inkey substitute that, even though it looks like it is cranking, drops the CPU utilization from over 40% to under 2%.

I created a function called new_Inkey() at the end of getSys.prg
FUNCTION new_Inkey(x)
LOCAL nKey := 0

DO CASE
CASE x == Nil .OR. valType(x) <> &quot;N&quot;
nKey := inkey()
CASE x <> 0
nKey := inkey(abs(x))
OTHERWISE
WHILE ( (nKey := inkey(.1) ) == 0 ) ; ENDDO
ENDCASE

RETURN nKey

In getSys(), there is only one call to inkey() and this I replaced with new_Inkey()

In my header files I add the following. ( not for getSys.prg )
#ifdef _NEWGETSYS_
#translate inkey(<x>) => new_Inkey( <x> )
#endif

Not sure if this will help you, but has worked for us over ther years.

 

[ArtieChappie]

We have found a &quot;fix&quot; called Tame which takes care of this. You will find this at

http://www.tamedos.com

 

[arainfor]

We use OSLIB.LIB, and is very good.
You can obtain this lib in

http://www.the-oasis.net

MB

 

[ProfReynolds]

A friend of mine gave me a solution that does not LOOK like it works, but does! The rest of this are his words:

I am not sure if this will help, but I created a work around a couple of years ago for the getsys and inkey() that has stayed in our programs since which does not use the third party libraries. I wrote a simple inkey substitute that, even though it looks like it is cranking, drops the CPU utilization from over 40% to under 2%.

I created a function called new_Inkey() at the end of getSys.prg
FUNCTION new_Inkey(x)
LOCAL nKey := 0

DO CASE
CASE x == Nil .OR. valType(x) <> &quot;N&quot;
nKey := inkey()
CASE x <> 0
nKey := inkey(abs(x))
OTHERWISE
WHILE ( (nKey := inkey(.1) ) == 0 ) ; ENDDO
ENDCASE

RETURN nKey

In getSys(), there is only one call to inkey() and this I replaced with new_Inkey()

In my header files I add the following. ( not for getSys.prg )
#ifdef _NEWGETSYS_
#translate inkey(<x>) => new_Inkey( <x> )
#endif

 

[GAstrada]

When linking apps to win 2k, not try to overlay the code, forget all that complex *.lnk or *.rmk files. Simply type &quot;clipper <myapp>&quot;, then &quot;blinker (6.0) <myapp> (incremental off)&quot;.
Good luck.

 

[Guest_imported]

if i use the OSlib, and nanfour libraries, i don have to use TAMEDOS.....what do you think

thanks for answer

alpert2@yahoo.com

 

[JQR]

Laurie321 can you give me more specific instructions on how you fixed this problem?

 

[Limsky]

Laurie321 can you give me detailed information on how you fixed this problem?
I have the same problem when I run Clipper application on Windows2000.

 

[waterstart]

Laurie321 can you please give me more specific instructions on how you fixed this problem?

 

[GAstrada]

Dear friends:

Believe it or not. When you try to make a suitable DOS environment under win 2000, you usually try to set the files to 100 or more into de c:\winnt\system32\autoexec.nt.
( and of course, in config.nt ).

well, if you write a pretty and readable:

set clipper = F100

...... will NOT work.!! certainly !!!!!!!

but if you write:

set clipper=F100

....... will WORK FINE !!!

Another bug from Microsoft ??

regards.

 

[Bozz]

I think it's more a case of everything that comes after SET<space> and before the = sign is the environment varialble.

Tidy isn't always best, you should see my desk! Ian Boys
DTE Systems Ltd

 

[majoshire]

HI Laurie:

Please help me with the same nt cpu problem you had. I am in dire need of this solution...
ben@yahoo.com

Ben lopez

 

[majoshire]

Hi Laurie, I'm in need of the solution you asked for at this forum back in January. I hope you can share this with me. Let me know.

thanks,

Ben lopez

 

[aker]

Hi.

malysg gave the solution of calling the dosidle() function at the beginning of your code, and including DOSIDLE.OBJ in the linking. Without this function being called, the processor is 99% occupied with ntvdm.exe, with it doesn't even register, ie. 0%. I don't remember where DOSIDLE.OBJ can be obtained but probably its at

http://www.the-oasis.net.

Regards.

 

[dalloca]

Ok.. no problem...the solution is the use of dosidle.obj and calling dosidle() at the beginning of your code. You can find it at:

http://spravki.net.ru/files/utils/DOSIDLE.RAR

regards