I have a CONSOLE app that I need to “pause” periodically for a brief period of time. Perhaps a second or two. I first tried to solve this with a Timer. I built a little test app that waits a period of time and then prints the current date/time. It work perfectly under MacOS and Under Windows 7…but it doesn’t work well under Windows XP. I know Windows XP doesn’t “like” timers. So I tried a second approach. The “DoEvents” command takes an optional argument that sleeps the current thread for a period and yields time to other threads or the system. So I set this for a second or two…and it work perfectly under Mac OS and Windows 7…but doesn’t work well under XP. I tell it to sleep the current thread for 1 second and …it actually sleeps for an indeterminate period…perhaps 15 - 20 seconds. I’m considering a third alternative whereby my Console app does NOT release time to the system and goes into a tight loop checking the system clock until it reaches some future time (perhaps a second or two in the future. Does anyone have any other pearls of wisdom…beside perhaps tell the Windows XP user to upgrade to Win 7 at least.
Have you tried putting the code in a Thread and then telling the thread to sleep for a period of time?
This is always worth repeating to anyone who will listen. 
If you do a loop checking for time but add App.Doevents into it, you should have your cake and eat it too. App.DoEvents will regularly release resources, but you will be able to resume on exactly the time you want.
Ok…I took a third stab at the problem…and I told the system to give me the current Microseconds from the system uptime clock. Then I take the user supplied value (in seconds) multiple by 1 meeeeelion and add it to the variable that holds my original system uptime. I then put the system in a TIGHT loop to poll Microseconds until it’s greater than my calculated future time.
This too works great on Mac OS and Win 7 (well…it does tend to burn up CPU cycles on one core…but it works) – again it was not giving me the expected result on Win XP. I’ve discovered the problem. The problem is the test condition it self. I wrote this program specifically to test a “pause” operation. When I start the program…with a requested wait time of ONE second…it takes about 15 seconds before the program completes the “1 second pause”. So…no matter whether I use a TIMER or DoEvents or Burn Cycles…I get the same result… because… apparently…it takes 15 seconds to load the framework 
This when I run the little program that is supposed to wait 2 seconds and print “hello world” – it takes about 17 seconds to get the result. (15 seconds to load the frame work…plus an accurate 2 second wait time) Ohhhhhhhh snap. Loading the framework on more modern hardware and OS is PDQ and effectively transparent. So long as the “larger” task is running in the framework…a “pause” in the routine should work fine. Thanks to the respondents for taking time to consider the issue.
It’s worth noting that the tight loop solution could get your app terminated if it sits for too long. Windows will display a dialog which says that your app is unresponsive.
I would definitely opt for one of the first two solutions. Actually a single “doEvents” with an optional sleep time seems to be the most efficient. Much less troublesome than a timer running in a separate thread. In this instance (strange though it may be) I really wanted to write a small program that would pause for a configurable amount of time before doing something… this program is called by yet another program via the shell class, The problem is that I can’t wait for 15 seconds for an instance of the console framework to load. I need this program to provide a more immediate result. No matter what I do…it seems this just isn’t going to happen under Windows XP (I’ve tested the framework load on multiple systems with equally sluggish results). If I turn the program into a “service” the framework probably persists in the background such that I could send the service a message with a small pause and get more immediate results. Installing a service is outside the scope of what I consider acceptable solutions to this problem…so I thin I’m going to have to look outside of XOJO for a solution. Too bad. The solution works perfectly for Windows 7 and/or Mac OS.
Have you tried using a headless GUI app? Just to compare load times. 15 seconds is a ridiculous amount of time.
Wait a sec. Do you have that really big unicode dll? If so, compile under 2014r2 and see if it makes a difference.
Actually… as luck would have it…I am compiling under 2014r2. The only dll’s delivered are:
msvcp120.dll msvcr120.dll and RBConsoleFramework.dll
I did test multiple Win XP systems…I changed the program to do practically nothing but just print a message to stdout with no delay. If someone would like to confirm these results… Here is the entire “run” event for my console app.
StdOut.WriteLine("Hello World "+Str(new date))
Quit
I compiled this work Windows and it seems to work very well under Win7. Windows XP…not so much.
My test results showed very consistent 15 second run times.
UPDATE:
Maybe it has something to do with the StdOut.Writeline method.
I note that Print() is supposedly just an alias for StdOut.WriteLine. I considered maybe…it the “new date” or the “string conversion”— so I updated my program as follows:
StdOut.WriteLine("Hello World ")
Quit
That’s it. Can’t get much simpler…and it still takes 15 seconds to run under my test XP systems. Yes…it’s great reason to put XP out of it’s misery. Unfortunately… XP is something I’m going to have to deal with for a little while. I guess I’m just curious now if anyone else can confirm these results. Maybe it’s something to do with an XP service pack…or anti-virus…or something.
a 15 sec load time for console applications on Windows immediately rang a bell in my head. There was a feedback report some while ago describing this for Win2k3 which is quite similar to XP: <https://xojo.com/issue/28048> maybe this is the same problem? As apparently this cannot be reproduced by all XP users, it may be wort to compare the ServicePack level etc of the test-machines.
Right now I can not reproduce the delay on startup of console apps anymore. Unfortunately I have no clue what the reason was - no new software except for ongoing windows/antivirus updates was installed on the Win2003 servers that exhibited the symptoms. We never had the delay on Win XP machines and we experienced it only when building with Xojo never wirh RB versions. Checking with the freeware tool dependancy walker showed that loading the framework dll was what took so long.
Here is the title of the original post:
Xojo Console Programs load extremely slow on Win2003 Server
Antivirus can certainly get in the way. Avast is a real pain in the butt.
At the time we still had the problem, disabling antivirus for a test did not make a difference. But antivirus updates can bring other/newer versions of system dlls with them. And no, we never used Avast.
Perhaps this little issue is related…
About a year ago I was making a Xojo web application, building and testing initially under XP and I found that it took a long time to start up when run as a command, but was quite OK when run as a service.
The same application did not have a slow start under later versions of Windows.