Hello, what is the first version of Clarion to support 64-bit architecture?
Clarion does not generate 64-bit programs/DLLs.
But the IDE to run in 64bit?
I use Clarion 6 which is not good for 32bits, and in fact for 32bits?
Sorry, I misunderstood your question.
Clarion 7.x was the first version of Clarion IDE that was 32-bit and would run on a 64-bit computer.
I would not recommend using Clarion 7! You want to use something a lot newer.
2 Likes
That was my question, which IDE version ran in 64bit. I’m testing Clarion 9, is it worth it?
What is the best version to migrate from version 6 app?
This information did not generate exe/dll for 64bit I did not know.
it’s definitely worth it.
There are some adjustments getting used to the new IDE, just like any significant change.
I would not migrate to anything less than Clarion 9.1. That was a very stable version.
The final version of Clarion 10 is also a good version.
I primarily use the Clarion 11 IDE with the Clarion 10 compiler for my projects.
That is another benefit of the new IDE. You can use the IDE from one version of Clarion and then setup multiple other Clarion versions in other folders and use all of them from a single IDE. This let’s you migrate to the new IDE and still use the compiler from older versions or setup “test” versions of Clarion that you want to experiment with without actually changing the primary Clarion folder.
1 Like
Taking advantage of your knowledge. To perform the ERP migration from version 6 to 9.1, do you need a lot of adjustments? Code, visual or adaptations adjustments?
Unfortunately, a lot of converted our C6 apps a long time ago and it gets harder to remember everything involved.
Here is some good advice in another ClarionHub article.
I agree with the advice that you should fix all problems in your Clarion 6 version of the program and then remigrate over to your new version. If you find more problems, fix them first in clarion 6 and repeat.
You’ll need updated version of your 3rd party tools, especially if they contain compiled Clarion dependent DLLs.
1 Like
I agree with Rick. Fix things in C6 and re-import in sucessive iterations.
Most of the adjustments that are needed really get down to the compiler and appgen fixing all the gray areas.
If you use Legacy templates I think there is something about the RETURN from routines. ABC is pretty much ok
Depending on the app it might be as easy as Just Open it in C11 and off you go.
2 Likes
I agree 9.1 was “stable” but I recall there were some annoying bugs that would make 10 my suggested minimum. For a new conversion use 11 and be as up to date as possible from the start.
One I recall was if the first control to take focus on a window was a Button it would not always display. Look at PTTS reports for more.
It’s been a long time since I used 9.1 so I could be wrong and I know some big projects are using it.
And is using Clarion AnyScreen an alternative? I think of something less traumatic than the migration to a new version.
Something like GO-Gobal, to make desktop apps available on the WEB.
That is a completely different topic. 
AnyScreen is only in Clarion 11+, so you would need to migrate your solution to a new version to use that.
I would look at TSPlus vs. Go-global if you want to publish a desktop app on the web.
There isnt a 64bit version of Clarion yet, it produces 32bit code.
This links below might give you a better insight into the difference between the different parts of Windows 32bit and 64bit.
Process Interoperability - Win32 apps | Microsoft Docs
On 64-bit Windows, a 64-bit process cannot load a 32-bit dynamic-link library (DLL). Additionally, a 32-bit process cannot load a 64-bit DLL.
On 64-bit Windows, an out-of-process 32-bit COM server can communicate with a 64-bit client, and an out-of-process 64-bit COM server can communicate with a 32-bit client. Therefore, if you have a 32-bit DLL that is not COM-aware, you can wrap it in an out-of-process COM server and use COM to marshal calls to and from a 64-bit process.
In-process servers are currently registered using the InprocServer registry entry. On 64-bit Windows, 64- and 32-bit in-process servers should use the InprocServer32 entry.
To port handles, which by their nature are local to the computer and would never be used across the 32-bit to 64-bit boundary, use the HANDLE_PTR type instead of the INT_PTR or DWORD_PTR type. This includes porting RPC interfaces passing such handles as DWORD values. The 64-bit HANDLE_PTR is 64 bits on the wire (not truncated) and thus does not need mapping. (The 32-bit HANDLE_PTR is 32 bits on the wire.)
Designing 64-bit-Compatible Interfaces - Win32 apps | Microsoft Docs
Porting from 32-bit Windows to 64-bit Windows should not, by itself, create any problems for distributed applications, whether they use Remote Procedure Calls (RPC) directly or through DCOM. The RPC programming model specifies well-defined data sizes and integer types that are the same size on each end of the connection. Also, in the LLP64 abstract data model developed for 64-bit Windows, only the pointers expand to 64 bits—all other integer data types remain 32 bits. Because pointers are local to each side of the client/server connection and are usually transmitted as NULL or non- NULL markers, the marshaling engine can handle different pointer sizes on either end of a connection transparently.
However, backward compatibility issues arise when you add new data types or methods to an interface, change old data types, or use data types inappropriately. The following topics discuss how to avoid these situations (when possible) and how to design robust workarounds when it is not possible to avoid them.
Now if you have an issue with 64bit MS Office products, this might help you.
Choose between the 64-bit or 32-bit version of Office (microsoft.com)
The 64-bit version of Office is automatically installed unless you explicitly select the 32-bit version before beginning the installation process.
Reasons to choose the 32-bit version
- You have 32-bit COM Add-ins with no 64-bit alternative . You can continue to run 32-bit COM add-ins in 32-bit Office on 64-bit Windows. You can also try contacting the COM Add-in vendor and requesting a 64-bit version.
- You use 32-bit controls with no 64-bit alternative . You can continue to run 32-bit controls in 32-bit Office like Microsoft (Mscomctl.ocx, comctl.ocx), or any existing 3rd-party 32-bit controls.
- **WindowsAPI using 32-bit data types like long, for pointers and handles. In most cases, adding PtrSafe to the Declare and replacing long with LongPtr will make the Declare statement compatible with both 32- and 64-bit. However this might not be possible in rare cases where there is no 64-bit API to Declare.
- You have 32-bit MAPI applications for Outlook . With a growing number of 64-bit Outlookcustomers, rebuilding 32-bit MAPI applications, add-ins, or macros for 64-bit Outlook is the recommended option, but if needed you can continue to run them with 32-bit Outlook only, as well. To learn about preparing Outlook applications for both 32-bit and 64-bit platforms, see Building MAPI Applications on 32-Bit and 64-Bit Platforms and the Outlook MAPI Reference.
You’re activating a 32-bit OLE server or object . You can continue to run your 32-bit OLE Server application with a 32-bit version of Office installed
Compatibility between the 32-bit and 64-bit versions of Office | Microsoft Docs
The above is just some of the considerations you might need to make because I know some apps communicate with Office products.
ODBC tool displays both 32-bit and 64-bit - SQL Server | Microsoft Docs
Rules for Using Pointers - Win32 apps | Microsoft Docs
Rules for Using Pointers
- Do not cast pointers to int , long , ULONG , or DWORD .
If you must cast a pointer to test some bits, set or clear bits, or otherwise manipulate its contents, use the UINT_PTR or INT_PTR type. These types are integral types that scale to the size of a pointer for both 32- and 64-bit Windows
- Use the PtrToLong or PtrToUlong function to truncate pointers.
If you must truncate a pointer to a 32-bit value, use the PtrToLong or PtrToUlong function (defined in Basetsd.h). These functions disable the pointer truncation warning for the duration of the call.
Use these functions carefully
3. Be careful when using POINTER_32 values in code that may be compiled as 64-bit code. The compiler will sign-extend the pointer when it is assigned to a native pointer in 64-bit code, not zero-extend the pointer.
4. Be careful when using POINTER_32 values in code that may be compiled as 64-bit code. The compiler will sign-extend the pointer when it is assigned to a native pointer in 64-bit code, not zero-extend the pointer.
5. Be careful using OUT parameters.
6. Be careful with polymorphic interfaces.Do not create functions that accept DWORD parameters for polymorphic data. If the data can be a pointer or an integral value, use the UINT_PTR or PVOID type
- Use the new window class functions.
If you have window or class private data that contains pointers, your code will need to use the following new functions:
These functions can be used on both 32- and 64-bit Windows, but they are required on 64-bit Windows. Prepare for the transition by using these functions now.
Access all window and class data using FIELD_OFFSET .
The LPARAM , WPARAM , and LRESULT types change size with the platform.
32-bit and 64-bit Interoperability - Win32 apps | Microsoft Docs
The above are just snippets of pertinent information taken from MS and more detail can be found in the links on the MS website.
Unless you are trying to work with a 64bit database and it doesnt have a 32bit interface like what you see in the 32/64bit ODBC interface link, I dont think you will have any problems for the foreseeable future, certainly for next five years imo, but who can fortune tell? 