[Feature request] - Migrate current project to Xojo (cross platform language)?

[gitnewcomer]

Hi @tannerhelland,

Visual Basic 6 is some decades old, did you ever thought about migrating this great project to some cross platform language that is very similiar to VB6 like Xojo? This will give your project the oportunity to reach other OS's! :)

https://documentation.xojo.com/topics/migrating_from_other_tools/migrating_from_visual_basic.html

[tannerhelland]

Hello @gitnewcomer . Migrating a free, volunteer project with hundreds of thousands of lines of code to a new language is simply unfeasible. It would take me decades of work, and I would rather spend my limited energy improving PhotoDemon as it is.

If a corporate sponsor stepped up and paid me to do a migration like that, then sure - I might consider rewriting PhotoDemon in a new language. But excepting that, PhotoDemon will always be a VB6 project.

PhotoDemon is open-source of course, so other (insane) people are welcome to attempt their own migration of PD to some other development tool!

[wqweto]

Btw, the insane people at TwinBasic discord server are already attempting ports of PD to x64.

Most impressive is that current PD project and source code import, compile and run targeting x86 output binaries.

[fafalone]

I think wqweto is psychic, I didn't tell anyone I already started a little x64 conversion work on PD. Must have known I wouldn't be able to resist when we started talking about it lol

But yes huge progress in tB. Even a few weeks ago PD didn't run in it at all. Now it's not only running, but largely working. There's some bugs, some big like the RGB color wheel overflow on mouseover, but the unmodified VB6 source runs, can open, edit, and save photos, and the recovery even works when it crashes.

While porting to a different language is impractical, I think PhotoDemon could definitely become a 64bit capable twinBASIC project, and at least get the RAM benefits and future proofing of that, which can be done while maintaining VB6 compatibility, if not begin to take advantage of numerous features tB has to make the existing VB6 language more powerful and extend it into a proper successor-- though might want to wait for tB 1.0 before even considering moving beyond VB6 compatibility.

[WaynePhillipsEA]

@tannerhelland I'm the developer of twinBASIC. I was holding off reaching out to you until we had a few of the "showstopper" issues ironed out but as others have mentioned, we can already load and run PD in the latest releases of twinBASIC. It would be great to have a chat with you about the work we'd like to do get your project adapted for 64-bit support.

Are you on discord? We have a discord server with 500+ members if you'd care to join us for further informal discussions: https://discord.gg/UaW9GgKKuE

[mansellan]

As its not been mentioned so far in this thread, I thought I'd mention as of now, twinBASIC can compile to WIndows x86 (the goal is 100% source compatibility with VB6) and Windows x64 (existing VB6 projects will need some API work, @fafalone is an expert there), but from the very beginning the plan has been to provide multi-platform support. This should be a much easier path to x-plat for PhotoDemon than a full rewrite in a new language would be.

Any Windows-specific API calls would of course need to be reworked, and the UI layer will differ, but that would also be true of moving to another language in addition to all the other overhead.

[tannerhelland]

Oh wow, thank you for the comments, everyone. twinBASIC has clearly come a long way since the last time I checked (which was... late 2022, I think?)

twinBASIC is an entirely different beast from Xojo, and I'd love to learn more about how I can help get PhotoDemon running on it. I will open a new dedicated issue on that momentarily and tag those who commented here. Thank you so much for catching me up.

[gkjpettet]

No affiliation but have you taken a look at RemObject's Mercury compiler (https://www.remobjects.com/elements/mercury/)? It can compile VB to a bunch of different architectures. I'm a very happy user of the project.

[yogeshvachhani]

No affiliation but have you taken a look at RemObject's Mercury compiler (https://www.remobjects.com/elements/mercury/)? It can compile VB to a bunch of different architectures. I'm a very happy user of the project.

But does is have a visual IDE?

[gkjpettet]

Ah no it doesn’t have a visual editor.

In that case, I’ll give another vote for Xojo. It’s very close to VB but is desktop cross platform with one code base.

[gitnewcomer]

No affiliation but have you taken a look at RemObject's Mercury compiler (https://www.remobjects.com/elements/mercury/)? It can compile VB to a bunch of different architectures. I'm a very happy user of the project.

You probably missed that this project is developed in Visual Basic 6 and not Visual Basic .NET... From what I've seen, Mercury compiles Visual Basic .NET projects... Correct me if I'm wrong...

[gitnewcomer]

Ah no it doesn’t have a visual editor.

I've seen that they do have an own IDE called "Water" for Windows and "Fire" for MacOS... They also support integration with Visual Studio... But like I told, they don't support Visual Basic 6, but Visual Basic .NET, witch isn't completely the same as Visual Basic 6...

[tannerhelland]

Switching compilers is certainly an easier task than switching languages, but as mentioned above, there aren't any compatible VB6 compilers except maybe twinBASIC (as it continues to evolve).

PhotoDemon has especially challenging needs this way because it can't run as an interpreted language and still have the performance necessary to edit photos. Anyone with access to a VB6 compiler can see this easily by compiling to P-Code (VB6's non-native-code variant) and then trying to use almost anything in PD.

PhotoDemon is tightly wedded to Windows because PhotoDemon runs on its own UI toolkit and that toolkit was built against Windows many many years ago, long before it was feasible to do something like that on the web. You can look through the source and if you have any familiarity with Windows development, you'll see thousands of calls to Windows-specific UI libraries. This would all have to be rewritten against a cross-platform UI toolkit, which is the really ugly part of cross-platform support. I genuinely do not see that happening under any circumstances, because PhotoDemon and Windows are inseparable.

I wish it wasn't this way, but it's simply how the project originated. (I wrote Windows imaging code for work and PhotoDemon started as a place for me to collect various imaging algorithms as I prototyped them.)

Multi-platform photo editors all run atop existing cross-platform UI toolkits (e.g. GIMP and GTK, Krita and KDE, Photopea and the web), and PhotoDemon wasn't written that way. It would have to be rewritten from scratch as a different application to ever run on something other than Windows. 🤷 Alas!

[fafalone]

Just out of curiosity, does PD run with WINE? That's at least a little cross-platform support. I see an issue with WINE/Arch Linux but don't know if it's specific to that.

Removing the msvbvm60.dll dependency might help with that as I hear it's a bit buggy under WINE, which twinBASIC will do (even for specific user-inserted calls to it: tB has internal implementations of the most common functions, covering all of the ones used by PD I believe, and automatically replaces DLL calls to it with the internal versions).

[gitnewcomer]

Just out of curiosity, does PD run with WINE?

Also out of curiosity, did anyone already tried PD on ReactOS (https://www.reactos.org)? Maybe there is an interest to be the official "Paint" from this open source Windows OS... :)

[tannerhelland]

PhotoDemon runs on Wine... sometimes. Rarely. Depending on planetary alignment, goat sacrifices, etc. /s

(This is in no way a commentary on Wine - it's amazing and so are its devs, but Windows barely works when it's written by Microsoft and re-implementing it from scratch is unthinkably hard.)

I used to test PD under Wine more often (and still do occasionally) but PD's support matrix is already complex, and Wine multiples that by like 10,000x. PD worked pretty well on Wine for many years, but something changed a few years ago and I'm not sure if it's something I changed or if something regressed in Wine.

You might be able to get it to build if you supply your own copies of msvbvm60 and gdiplus.dll in particular (Wine's GDI+ coverage relies on cairo and that really hurts PD's performance). But lately I've struggled to get PD to even start correctly under common Wine configs, and I haven't spent enough time to track down where things are failing.

Maybe ongoing work on Proton will improve things in the coming years. IDK.

[mansellan]

twinBASIC redirects msbvm60 calls to internal implementations. Not sure how full the coverage is.

GDI+ sounds like a big can of worms though.

[fafalone]

Searching the PD source code, tB covers all the msvbvm60 functions used, so that won't an issue.

I've updated the features list to be more clear on VarPtr; tB will handle the VarPtrArray too. And to be more clear in general that it will redirect signatures as-is, not just provide an internal version with one version of the arguments.

GDIP+ though... yeah. I've got the 64bit declares written already (minus any PD-specific changes needed), but there's no internals for that.