I have only open information, perhaps someone has special access (not the story about the number from the hat) ?
Not easy to imagine a world where those with special access divulged privileged inside knowledge, yet continued to have special access.
Insider information about C12 is unlikely to lead to a decline in the US dollar. 
It is interesting to know if SV & RZ will please us with a message once a year or if there are other plans.
So I have 2 questions of what to expect with CW12
-
Will it still generate 32bit apps so I don’t have to worry about any conversions needed for full 64bit?
-
Will the new AI features allow it to convert my Legacy app to ABC with great accuracy and make it easy to identify issues and offer valid suggestions.
#2 alone will make it worth the upgrade. I really want to get all my apps in ABC to make my application suite easier to reuse code/dlls etc.
My understanding is that at this point it’s still going to be a 32bit compiler, so yes.
This first release will get unicode, which is needed for the 64 bit APIs, so part way.
Only Z can tell us about your number 2.
1 Like
To the first question - definitely yes. Even once 64 bit becomes available (not this version) its still gonna keep making 32 bit for a while.
Obviously we dont have details on the AI part, but my instinct would suggest that “no” it wo t help much with Legacy to ABC conversion.
But frankly, you dont need the IDE to do that. My guess is that you could do this already today with Claude or whatever, its an issue of simply getting the AI to convert one procedure (TXA) at a time.
Id recommended contracting John to get you started - hes got a lot of experience with AI tools, approaches, prompts and so on.
2 Likes
Will the development environment itself become C12 x64 ?
When working in C11.AppGen for a long time, there are problems with memory leaks. 
The dev IDE is .net. So it already is.
Memory leaks are a different issue entirely. Some have been addressed over time. I’m sure that will continue into the future.
1 Like
Thank you. The Clarion development environment has become unique, using x32 memory addressing. Perhaps this is due to the support of C6 RunTime for almost 20 years.
Igor, The c11 ide will always be 32-bit, because it uses win32 component calls. To make it 64-bit, you need a 64-bit compiler. RZ said that there was no point in developing a 64-bit version of the topspeed compiler, instead he wanted to replace it with an open-source compiler with a 64-bit version. C6 runtime support has nothing to do with this.
2 Likes
well one wonders what sort of LLM clarion will ship with but they did say support multiple AI providers…
GPT seems a world class random warbler … must try Gemini to see if it can actually do a real world task and repeat its accurately and keep context…
see windows supports utf-8 since version 10.
To clarify;
Much of the Clarion Runtime Library is written in C. Currently this is compiled (by SV) using Topspeed C.
What Bob said was that (internally) they may switch it over to another C compiler.
This is completely transparent to us as Clarion developers. We dont see the C sources, we dont compile them. It has zero effect on you, your programs, or your development.
This falls into the category of “interesting” but also “meaningless”.
Clarion is heavily tied to the topspeed compiler. I think replacing it with another compiler is not a trivial task. If you believe that SV can do this, then you should continue to wait and pay for a subscription. If we are realistic, what SV can really do for Clarion is to connect AI and a resizer for AnyScreen.
1 Like
To be clear (again) - we’re talking about the Topspeed C compiler here, not the Clarion language compiler. Replacing one C compiler with another C compiler is not a huge task. Yes it’ll take work, but it;s well within the realm of any C developer.
They are not talking about replacing the Clarion compiler with another compiler.
And such a compiler replacement may allow Clarion to use memory like all modern x64 development tools?
No. It’s part of the puzzle, but not the hard part.
Your programs consist of 2 parts (broadly speaking) - the code you write and the runtime-library DLL’s.
The code you write is compiled with the Clarion compiler. This currently generates machine code (assembly) using x86 32 bit machine instructions.
The RTL you use is (mostly) written in C. It’s currently compiled with the 32 bit Topspeed C compiler. Changing it to another C compiler would allow it to be compiled to x64 machine code instructions.
So, changing out the C compiler is part of the puzzle - an important part.
However;
a) the RTL code would still need to be adapted to 64 bit. There are a few differences between 32 bit C code and 64 bit C code.
b) SV still has to make a 64 bit compiler (because there isn’t any compiler out there that will compile Clarion source code to to the x64 instruction set.)
- There will also likely need to be some changes (hopefully not too many) to the code. All OS calls for example would need to be updated, all calls that you use to external C DLL’s like ZLIB etc as well. Again, this is not hard work, but it will need to happen. If you are mostly using 3rd party code for this sort of thing then obviously that work falls on that 3rd party supplier and makes your life easier.
There are other things SV would still have to do - the Linker for example - but the compiler, and compiling the RTL’s are the large part of the puzzle.
1 Like
From what I thought I understood from Robert’s discussion, one of the benefits to the developers would be the ability to utilize other debuggers.
I wasn’t clear on whether the Clarion debugger would be brought forward or if it would be redundant.
Thanks! I wanted to ask not about the application being created, but about the Clarion development environment itself.
Will replacing the compiler allow you to create a Clarion development environment without restrictions on the use of 4 GB (x32) RAM?
There are no modern development tools running under Windows x32 anymore.
1 Like
32bit apps, where the linker allows, can go upto 3GB on windows x32bit. 4Gb on windows x64bit.
If you need more, you have to go 64bit and use a linker that can do x64bit, but even that is restricted by windows as seen in the link above.
There was talk of using a different compiler and linker, but it wasnt clear if that option/path would compile clarion code, or whether templates would generate code in another language.
When looking at topspeed assembler, its based on 8086/286 instructions.
I saw something which suggested later assembler instructions could be used, but cant find it atm and I was going through dos masm and the topspeed reference at the same time.
If topspeed assembler can link in later intel cpu instructions, then writing you own compiler is a time consuming option.
I do wonder if SV have the skills and/or budget to bring it upto date.
The lack of a 3Gb/IMAGE_FILE_LARGE_ADDRESS_AWARE linker option so 32bit clarion apps can use 4Gb on 64bit would buy SV time until a 64bit clarion compiler is ready.
But there might be an obscure compiler flag that does this now, but Im not aware of it, if one exists.
I would like to understand what this phrase means. Topspeed C and Clarion compilers have different front parts and a common back part. The front provides syntactic analysis of the code in the programming language, the back translates the received intermediate byte code into machine code. If SV wants to abandon the topspeed C compiler, then it is logical to assume that there will be no topspeed Clarion compiler. From what RZ said, I understood that he wants to follow the same path as in clipper and foxpro. That is, to make a translator from the clarion language to the C language, and then use a 64-bit open-source C compiler.