Migrating from VB6

[axisdj]

Hello,

As I assume many here moved to PureBasic as vb6 is no longer supported.. I have been looking for a cross platform alternative to VB6 and it appears pureBasic now fits the bill!

I am looking to migrate 2 100k LOC projects from vb6 to Purebasic, has anyone had success doing this? Are there any tools that help with this? how close to VB6 is pureBasic ( general question... just looking for the gotcha's)

thanks

[Olli]

Tools, that's us.

[SPH]

Hello,

As I assume many here moved to PureBasic as vb6 is no longer supported.. I have been looking for a cross platform alternative to VB6 and it appears pureBasic now fits the bill!

I am looking to migrate 2 100k LOC projects from vb6 to Purebasic, has anyone had success doing this? Are there any tools that help with this? how close to VB6 is pureBasic ( general question... just looking for the gotcha's)

thanks

https://www.purebasic.fr/french/viewtop ... chaumieres

[dcr3]

Post subject: Re: Migrating from VB6 Reply with quote
Tools, that's us.

So True.

[axisdj]

Hello,

As I assume many here moved to PureBasic as vb6 is no longer supported.. I have been looking for a cross platform alternative to VB6 and it appears pureBasic now fits the bill!

I am looking to migrate 2 100k LOC projects from vb6 to Purebasic, has anyone had success doing this? Are there any tools that help with this? how close to VB6 is pureBasic ( general question... just looking for the gotcha's)

thanks

https://www.purebasic.fr/french/viewtop ... chaumieres

Thank you, but that will convert from vb.net, I am looking for a solution for vb6. This will mean I will need a way to convert my classes to work in PB.

ANY further experienced guidance will be greatly appreciated, moving from a large VB6! project to PB.

[mk-soft]

Classes in VB6 ?

Purebasic is function (procedure) oriented and not class or object oriented.
You can program classes and object oriented with Purebasic, but it is not directly supported like VB6. But this is possible with more effort.

See for example in my signature OOP-BaseClass

[deeproot]

Hi axisdj

Please see my post in this thread - viewtopic.php?f=7&t=69952 - I still stand by those comments.

Further thoughts and personal observations :

-- PureBasic and VB6 are different languages (as indicated by mk-soft), even though some experience is transferable - best to embrace and enjoy that!

-- Avoid attempting to force your new PureBasic code to behave exactly the same as VB6 - do things the PureBasic way!

-- I do not believe there is any software tool that will effectively aid migration of large codes. Best to manually work through each section of the program to adapt and rewrite for PureBasic. Yes, it's slow but the end result will be good and very likely a better product that the original VB6.

-- Before starting a very time consuming conversion, assess if there are any functions of your application that are specially difficult or not directly possible using PureBasic. If so then either solve them first with small trial projects or else you may need to re-evaluate you language choice! I didn't find anything serious, it was always possible to make an equivalent solution.

In hindsight there is only one thing I would have done differently - start my migration earlier!

[Keya]

VB6 native code is generally very easily translated to PB, but it becomes tricky when translating things like ActiveX objects which VB6 natively supports but PB doesn't

[skywalk]

Same with many here. I migrated using self written VB6 to PB conversion code written in PB. That served 2 purposes. Learn PB and rewrite my big apps at same time.

[axisdj]

@deeproot, I am no longer concerned about purebasic being popular enough.... I am at the point where I do see it as a viable option.

I have migrated some of my code as an initial small test project to Lazarus (cross plaform delphi style ide/compiler)(using vbTo converter, then hand correcting where needed) for a small mac app I wrote, and it worked out OK, but I just really prefer the BASIC syntax.

So let me ask a more direct question. As far as activeX, I really am not concerned about that, in all my new designs I try not to use any third party dll's or OCXs I do not have the source for.

What my main concern now is how I would convert my classes. I assume it requires a whole new perspective of possibly converting many of the classes into structs and in a functional manner writing functions that accept those structs as arguments. I do wonder how much my code base would need to change since I use objects allot. I suppose each object can be converted to a struct to hold variables, and all associated functions could reside in the same source file.

Am I somewhat understanding what would have to be done?

thanks

[TI-994A]

...my main concern now is how I would convert my classes...

While integration with external/system OO code is not impossible, requiring emulation of class-based protocols and interfaces, it's easier to refactor our own class code into the procedural paradigm which PureBasic utilises.

Rather than speculating on the adaptability of your code into PureBasic, it might be best to post a sample of one of your classes, and see what the community comes up with. It'll be a good first step towards a decision.

[Marc56us]

Hi axisdj,

I have migrated programs from time to time, and realized that the original pseudo-code and flowchart were far more useful than the code itself.

Indeed, every language has its strengths and raw conversion (when it exists) often gives bad results.

A migration is also often the opportunity to rid a program of unnecessary functions and to use simpler and more efficient methods.

Besides, with age, we write much cleaner, more concise and efficient code (Who hasn't had a big smile when we reread an old code 10 years later: "Who wrote this horrible algorithm? .... um, ohoh, me...uh? I was young. Del, del, del then 3 lines to replace 50.")

All this without forgetting that many external functions are often included in the language.

In PureBasic, Lists (once understood) are an extraordinary way (simple, fast, versatile) to manage masses of variable data, much more easily than the classical Dim.

[deeproot]

Besides, with age, we write much cleaner, more concise and efficient code (Who hasn't had a big smile when we reread an old code 10 years later: "Who wrote this horrible algorithm? .... um, ohoh, me...uh? I was young. Del, del, del then 3 lines to replace 50.")

..... This is so true!! All good comments Marc56us.

[spikey]

What my main concern now is how I would convert my classes. I assume it requires a whole new perspective of possibly converting many of the classes into structs and in a functional manner writing functions that accept those structs as arguments. I do wonder how much my code base would need to change since I use objects allot. I suppose each object can be converted to a struct to hold variables, and all associated functions could reside in the same source file.

The most important thing to realise up front is that although PB implements modules and they offer some of the same features as OOP - isolation, encapsulation - they aren't classes in the OOP sense and won't behave exactly as such, for example they don't "automatically" instantiate or dispose of "objects". They collate the code - not the objects.

Understanding this will prevent you from running up the "a module is a class" blind alley, which some OOP trained programmers have failed to spot in the past.

But once you realise that there really isn't any significant fundamental difference at the microprocessor level between the below; and that whether or not you want to fiddle about with virtual tables is entirely up to you - you should be on the way down the right path. From the way you mention structs and functions above suggests to me that you've been thinking about this already.

Code: Select all

Object = New ClassName(attribute parameters)
; isn't really any different to
*StructurePointer = SomeModule::CreateFunction(attribute parameters)
;
; also
;
Object.Method(method parameters)
; isn't really any different to
SomeModule::MethodName(*StructurePointer, method parameters)

The only thing I ever completely failed to migrate to PB that I would have liked to was a COM addin for Microsoft Office 2000. I'm reasonably confident that this wasn't because PB couldn't do it but because there was a lack of publicly available documentation on some of the aspects that get concealed from the programmer by VB/VC. These would have needed to be addressed by a PB programmer properly (specifically the low level details of the necessary interfaces). However I'm not sure that COM addins for Office is even a thing anymore!

[Bitblazer]

Understanding this will prevent you from running up the "a module is a class" blind alley, which some OOP trained programmers have failed to spot in the past.

Modules are more like encapsulation attempts aka 'namespaces' (or a dll) to me, but thats just my subjective point of view from comparing my c# (OOP) and PureBasic experience.