I have a hand coded c5.5 program that has been working fine for years. When the app runs on win 10 it frequently locks up. Sometimes it will unfreeze by alt-tab/ alt-esc loops while stopping at another program along the way.
I see a couple of similar reports on this site. Some win10 machines it works ok. Others locks up every couple of seconds. I have a test box which is failing frequently now.
The users don’t really care if the issue is mine or win 10. They want a fix. They can’t change their os so my program will work.
Was something found/changed in the runtime library to address this in a later version of clarion? I don’t want to spend time to convert to a newer version just to have the same issue.
How on earth are we supposed to predict if some change to clarion in the last 20 years (Clarion 5.5 is circa 1999) will affect your program or not?
To be honest it does not surprise me that your C5.5 program has problems - it surprises me that it runs at all. (And good on it for doing that I guess.) As you point out your customers are upgrading their OS from time to time - it probably seems like a good idea for you to do the same to your programming tool.
but given that it’s been 20 years since you last updated I expect the upgrade will take significant time. There’s the threading-model changes (from Clarion 6 / 2001) to take into account. Plus the new IDE. Plus the new runtimes. Sounds like a lot of fun…
Not that I’m aware of, no. The last “random OS” problems I’ve seen was back in July with the .Net update that caused all kinds of process/networking issues.
A bit more information might help.
What DB are you using?
Is the EXE running locally or across the LAN?
Is the EXE manifested and signed?
Have you attempted to run it in compatibility mode?
What are the differences between the WinX boxes where it works and fails?
Why am I not inebriated after Tennessee’s win over Kentucky this evening?
Etc, etc…
Not sure what is different between boxes that work/fail.
Others have reported a similar lockup issue using clarion. Moving the app frame seems to be the easiest way to lock it up. No cpu spike. Seems to be waiting for a message/deadlock. Alt -tab/alt-esc/ctr-alt-del bring it back to life. I started to look at the spy++ output - hard to pinpoint it.
I had a inter thread communication on shutdown states that was not safe in the post 5.5 world. Fairly simple change (didn’t even have to use a lock object) and the program appears to be working ok.
Looking at other spots in the code for similar errors.