Anyone know why c5.5 apps lock up on windows 10?

Is there a way to use a c5.5 exe on windows 10 by adding a manifest or a window proc subclass or …?

The conversion to c11 is not going well.

I was helped on this site with a similar problem, maybe a year ago. My C5.5 was on Windows Vista and wouldn’t work on Win10. The funny thing was that an .exe produced on Vista a long time ago worked on Win10, but Clarion couldn’t be transferred to Win10. The explanation I got, was the difference between 16bit, 32bit and 64 bit o/s. When the processors changed from 16bit to 32bit, you could still run 16bit programs. But when it changed again to 64bit, you could no longer run 16bit programs (but you could run 32bit programs). The IDE of C5.5. is, at least partly, 16-bit. Therefore C5.5 is outdated. But it can produce 32bit .exe, so the old .exe should work on Win10. If the old .exe-file is 16bit, it won’t work (if you chose to make it 16bit). So with C5.5 you must develop on an older machine and compile to 32bit to make the .exe work on Win10.


I was looking for a specific message sequence that causes the 32 bit c5.5 apps to lock up when running on win 10.

I don’t know in more depth. I have just barely tried a 32bit C5.5 .exe on Win10 and seen it running. As long as it’s not a 16bit .exe, it could work, that’s all that I know…

try clicking on another program and back to the c5.5 32 bit program by clicking on the title bar. Usually it locks up after 1 or 2 attempts on windows 10.

I see what you mean. I tried an old program from 2006, “warkiv.exe” (warchive.exe), clicked back and forth, and the app died (but was still on the screen). I had to End Task with Task Manager. So you need someone with more expertise. If I was going to revive such an application, I would try to convert .dct and .app files and regenerate .clw and .exe with C11. I must admit I’ve never done it. The only program I upgraded, was handcoded (.clw only).

I posted a similar entry more than a year ago and was never really given an answer. Just told to upgrade to Clarion 10. I saw that when a screen consisted mostly of buttons and few or no entry fields, it would appear to hang when it lost focus. Usually hitting Alt-tab will get the focus back to the app but not always. I found screens with listboxes were not as likely to hang.

I agree with you, migrating to Clarion 10/11 is very painful and I have run into a multitude of threading problems which make absolutely no sense. Let me know if you find anything more with C5.5 on Windows 10.

I really wonder why you have so severe problems with upgrading to C10/11.
I find it mostly a question of hours instead of days when I have to do it.
Could be so, that you find one who is familiar with the task, and let him/her do the job to a clean compile.


If C11 was better than C5.5 it would just be the threading issue to resolve. C11 is not better than c5.5 for my application.

C11 is 30-50% slower performing create control operations. This is most of my program.

C11 gpfs/locks up when hidden windows are used.

C11 can not have as many images/icons linked in w/o splitting the app into a exe and dll for a linking issue.

My specific app is all hand code so I don’t appreciate any of the many improvements in the templates/app gen area.



I get your points, but:
The C5.5 dll’s is optimized for Windows XP/Win 2000
As Windows goes through more and more cycles, you suddenly find errors, which you just can’t resolve - You seems to have found one.
So my suggestion is still to upgrade - And it seems like my proposal for the way to do it was a bit impolite. I do not know you, but it seems like you are more experienced than I am, and at least have more knowledge about Clarion programming than I have.

1 Like

My flagship product, written C55, is now over 20 years old! I assure you that it runs PERFECTLY in Win10.

Do you use the in-memory driver? If you do, that could be the culprit.

I write A.I. software, which is a very system-intensive effort. About 10 years ago, I was using the in-memory driver and periodically the program would just crash. When I switched the driver to the Clarion format, the problem went away completely.

Hope this helps.

Dave Schwartz

You’re close - but slightly offtrack. It’s not the processor that matters, but the OS. So you can run 16 bits programs on a 32 bit OS but not a 64 bit OS. The C6 (and earlier) IDE is 16 bit so you can only run that on a 32 bit OS, not a 64 bit OS.

I’ve got a few C55 programs running on Windows 10. (Although most are small utilities.)
My guess is that, if you have a problem, it’s to do with threads. You mention your program is hand-coded, but you don’t mention if you are starting threads in it or not.

C6 had a very different threading model to C55, so if you are having issues it’s more likely from that period rather than the C11 period.

the key to starting threads in C6 and later is to do it slowly. What you don’t want is a number of threads being started “at the same time”. Ideally you want one to start, that posts an event back to the main thread, which then starts the second and so on. You definitely don’t want;

Also avoid starting threads “before” the current window has completly set iself up. That means ideally not starting from before the ACCEPT loop, or during the OpenWindow event. Rather post an event:User when your window starts, then on that event START the new thread and so on…

C11 gpfs/locks up when hidden windows are used.

I suspect this is related to the above. There’s nothing intrinsic about hidden windows that make them different. Just about every program I write, and since NetTalk has a hidden background window, I would guess the vast majority of all C11 programs have hidden windows. So this is either related to your threading issue, or you need to narrow down the scope of the problem more.

Let’s get the threading right first though, and move on from there.

In addition to starting the threads, there are of course all the other C5.5 to C6 upgrade issues to take care of. Specifically the use of Global, Unthreaded data - in most cases (especially queues) this will need to be made Thread Safe.



1 Like

I do say “o/s” (“16bit, 32bit and 64 bit o/s”). I’m so old that I use slash-notation (like in the early days with CP/M as the platform, before MS-DOS). Then I am not so accurate in the next sentence, but it is still true. When the processors changed, after a while the o/s changed, so the underlying reason for these problems is the change of processors. But I’m aware you can run 32bit o/s on a modern pc.


Multiple people report it locks up. Some win10 are ok and some lock up. Please try the method listed in the earlier reports and let us know.

Thanks for the reply. The hidden window lockup was posted and confirmed by tech support. I think they decided it was an edge case and was not going to be fixed.

Hi Jared,

I guess my point was that “generic” hidden windows are not rare. The vast majority of Clarion programs have them (even if people aren’t really aware that they are they, because, um, well, they;'re hidden :slight_smile: )
So it’s some specific aspect of your hidden window (other than, or in addition to the fact it is hidden) that is contributing to it locking up. Presumably if you can figure that part out, that would go some distance to fixing it.

But I’m aware that you’re clearly “well outside the box” - with the hand-code, creating controls and so on, so I’m guessing there’s really not a lot of useful advice I can give you. sorry.


Hi Bruce,

It is frustrating. I appreciate the help.

The simple hidden window code is in message Clarion 11 lock up with hidden windows