I have a massive FORTRAN Windows program with a Win32 GUI (menus, dialog boxes, lots of user interaction, etc.) coded in FORTRAN. I would like to use a XOJO GUI instead.
After reading XOJO documentation and numerous Forum threads, I’m wondering if this would work:
- Launch XOJO GUI.
- Load the FORTRAN code (without Win32 calls) as a DLL to XOJO. The DLL has the addresses of two memory blocks: one is for messages from XOJO to FORTRAN, the other for.messages from FORTRAN to XOJO.
- Both XOJO and FORTRAN start processing and initiate timing loops
- XOJO and FORTRAN use the timing loops to check the memory blocks for new messages and then to act on them
What do you think about this? Improvements? Thanks
This is at least possible, though fairly difficult. The difficulty lies in how well your existing UI is abstracted away from the data and logic of the application. If they are intertwined in the existing code, that’s going to be a significant challenge to figure out.
The memory block approach is probably not the best, due to sync issues, and there won’t be a native way to do this in Xojo. I would suggest you consider a socket instead, whether that’s a standard TCP socket or a local IPC socket. You’ll avoid a ton of issues this way. Plus, if you strictly go with the TCP route, your app will have the neat attribute of being network transparent, meaning you can run the UI on one computer and the backend on another machine.
This is going to be an adventure for sure if you decide to proceed. It’s going to be a lot of work - and frankly I wonder if you should consider simply rewriting the entire app in Xojo. You’ll end up with a modern codebase that will be easier to debug and maintain.
3 Likes
It could work but, if you are interested only on the GUI, I think Xojo is not the right tool.
For that kind of task is better to work with something more low level, Win32 calls directly on C++? wxWidgets? etc
Hello Mike, what is the real benefit of migrating a 32 Bit GUI ?
IMHO : do it once and do it right ….
BTW : speed etc, with the help of MBS a lot of things are possible.
Good luck
Rainer
If you can refactor your non-GUI Fortran code into a DLL then you can just use Declares in Xojo the same way you would write Declares to a Win32 API. At that point the API for your DLL is up to you. Passing and returning large data sets by pointer is fine. But I would absolutely avoid trying to create a messaging system via two blocks of memory. It’s needlessly difficult, rigid, and will not scale.
If your code is blocking (i.e. not threaded) then just call functions in the DLL and have those functions return a value.
If your Fortran code uses preemptive threads then you would have two functions per operation. One would initiate the thread and return an identifier to Xojo. The other would be a polling function that would allow Xojo to safely find out if the thread has completed so that it can then take the next step. That means there would need to be a little bit of thread/task tracking code in the Fortran DLL.
You could use a pointer to the memory block that will hold the output data as the identifier for the thread. But don’t get lazy and do something like set a flag in that block which Xojo reads periodically to see if everything is done. You have to have a safe polling function that Xojo can call from the main application thread. If the Xojo main thread and the task preemptive thread try to access the same address simultaneously it will result in a rare, difficult to trace, hard crash. So your Fortran DLL has to do things in a thread safe manner and provide a thread safe polling function to Xojo.
You can actually call a Xojo method from a DLL. But I’m not suggesting that here because there’s no way (that I know of) to do it safely from a preemptive thread trying to let Xojo know “hey I’m done.”
Another option would be helper applications that invoke the Fortran DLL (or potentially are just straight Fortran console apps). These could use the new Xojo helper framework, or you could roll your own. As Eric points out if you roll your own helpers using TCP then the backend can run on other machines. Now your Fortran DLL doesn’t have to deal with threads. However, if you have to pass large amounts of data back and forth from the GUI to the workers it’s going to be inefficient.
Which solution you choose depends very much on your existing Fortran code and your end goals.
2 Likes
Thanks folks. Your replies are truly helpful. My immediate concern was that I had missed something simple and obvious. It seems not. Now to investigate alternatives … Thanks again 
By the way, Xojo uses Win32 controls.
1 Like