VO Application ported to X#

[wriedmann]

Hello,

yesterday I was able to migrate my Dictionary Editor to X#.(it is a tool to design databases and maintain the string tables for translations)

This is a screeshot of the VO version:

DictEdit_VO.png (299 KiB) Viewed 645 times

and this of the X# version:

DictEdit_XS.png (322.93 KiB) Viewed 645 times

Wolfgang

[Chris]

Hi Wolfgang,

Thanks for sharing! Personally I already know the answer, since we've talked also by email, but maybe you could share also here your experience with porting the app to x#?

Obviously porting a VO app to x# is not a click and go thing, it requires preparation, effort and some patience for sure! But I think that after you gain some experience with this, it becomes much easier. If you'd like please share some of this, so other people know what to expect as well. When/if you have some time to do this of course.

btw, of course this goes also for everybody else who have ported their VO apps (or some of them)!

TIA,
Chris

[wriedmann]

Hi Chris,

So, if this migration interests someone, I'll post a few articles about it in this thread (a too long article is hard to read and hard to write).

First, let me explain the structure of my VO applications:

• The base library is the wLib2, that is about 20 years old and is enhanced when needed, at least once a month. It contains the base classes for servers, controls and windows and a lot of other functions and classes. This library contains only handwritten code and is shared between different projects through external modules.
• Then there is the BasicMapi lib, that contains basic mail functionality and DynMenu, the basic classes for dynamic menus (I don't use the menu editor because most menus are to build depending on the current user
• The next library is wLibDlg, that uses the first three libraries and contains the most used dialogs, like LookupDialog, ChoiceDialog and about 20 others.
• Next in the list is wStdBrowser, that uses bBrowser 4, defines my bBrowser base class and the standard databrowser window from which nearly all databrowser windows are inherited, and the relative filter functionality.
• And then, as last in the list, I have wErrorsys, my base error handler.

There are much more libraries, but they are loaded either dynamically like the Zip (using Compression Plus) or the report classes (using VPE), or used only by a few applications like the Vo2Ado or the MySql lib.

As you can immagine, first candidate in the migration process was the wLib2 library.

Since my libraries and my applications are living, I need the possibility to repeat the migration often, until all of my VO applications (about 50) are migrated to X#.
And the basic rule is to not change anything in the X# version of the library that is not changed also in the VO version.

And as last note: I have licenses to Vulcan 4 (as I'm currently subscribed also to VPS) and to the bBrowser4.NET.

Wolfgang

[wriedmann]

Before starting the migration of my most important library, I have imported the source code of the Vulcan version of the VO class libraries into my XIDE projects.
Then I have changed the names of the libraries from VulcanVO* to XSVO*, changed the compiler from Vulcan to X#/Vulcan dialect and compiled them.

xsvo_project.png (5.26 KiB) Viewed 645 times

Another note: on my C drive, I have a folder called DevNETLibs, where I put all compiled versions of my libraries:

devnet_libs.png (89.6 KiB) Viewed 645 times

Upon my request, Chris has added a special function in XIDE to copy the binaries of a project to a directory, and I use this funtionality to maintain my c:devnetlibs directory content up to date:

xide_copy_binaries.png (14.44 KiB) Viewed 645 times

When using then the libraries in an application references, I select them from the relative c:devNETlibs folder.

Back to the migration process itself: I created a new XIDE project, called VO to X# migration, using the folder C:XSharpXIDEProjectsVO_XS_Migration.

Then I fired up the VO-xPorter, selected the most recent version of my wLib2 AEF and used the following settings:

xporter.png (61.98 KiB) Viewed 645 times

Two settings are very important:

• the output folder points to the Applications directory of the new project
• and the "do not overwrite project files" is checked

These settings are important so I can repeat the migration process how often as I like without the need to reconfigure the projects settings after each run.

After xPorting the AEF, I added the application through the Project - Add application context menu:

add_application.png (33.76 KiB) Viewed 645 times

After this, the application was ready to be compiled, and I can assure that I was shocked about the number of compilation errors and warnings I received.

Please read the next message about some solutions I have adopted.

[wriedmann]

After porting my library the first time and fixing the references (replacing the VulcanVO* libraries by the XSVO* libraries), I was really surprised how few errors I had:

CompileErrors_Step1.png (96.56 KiB) Viewed 645 times

The 2 errors were only delegates added by xPorter:

Code: Select all

delegate DictClose_delegate() as void pascal

Easily changed to

Code: Select all

delegate DictClose_delegate() as void

and

Code: Select all

delegate EnumWindowsProc_delegate( hWnd as ptr, aWindows as array ) as word callback

to

Code: Select all

delegate EnumWindowsProc_delegate( hWnd as ptr, aWindows as array ) as word

These two issues will be fixed soon in xPorter.

Fixed these two, on the next compile the errors changed (with warnings hidden as I would concentrate on errors first):

CompileErrors_Step2.png (17.25 KiB) Viewed 645 times

I will list every type of error only once - and all changes were made on both the VO and the X# side, so I had code synchronized. Larger changes were only made on the VO side, and then moved to X# with a new xPorter run.

Code: Select all

error XS0029: Cannot implicitly convert type 'Vulcan.Codeblock' to 'string'

in this part of code:

Code: Select all

if cValidBlock == NULL_STRING
  cValidBlock := MCompile( cValidString )
endif

change to

Code: Select all

#ifndef __XSHARP__
if cValidBlock == NULL_STRING
  cValidBlock := MCompile( cValidString )
endif
uResult := MExec( cValidBlock )
#else
if oValidBlock == null
  oValidBlock := MCompile( cValidString )
endif
uResult := MExec( oValidBlock )
#endif

as MCompile has another definition in the Vulcan runtime. This correction fixed the first two errors.

Next error after recompile:

Code: Select all

error XS0619: 'Functions._RegisterExit(void*)' is obsolete: ''_RegisterExit()' is not supported.  Use an event handler added to the AppDomain.CurrentDomain:ProcessExit event instead'

on this code part

Code: Select all

if lInit == false     
#warning Callback function modified to use a DELEGATE by xPorter. Please review.
// _RegisterExit( @AxitGlobal() )
static local oAxitGlobalDelegate := AxitGlobal as AxitGlobal_Delegate
_RegisterExit( ;
System.Runtime.InteropServices.Marshal.GetFunctionPointerForDelegate(oAxitGlobalDelegate) )
  lInit := true
endif

This code was changed by the xPorter, and since I don't think the .NET runtime needs the RegisterExit anymore, changed to:

Code: Select all

#ifndef __XSHARP__
if lInit == false
  _RegisterExit( @AxitGlobal() )
  lInit := true
endif
#endif

Next error:

Code: Select all

error XS0619: 'Functions.Buffer(dword)' is obsolete: ''Buffer()' is not supported, use MemAlloc() and MemFree() instead'

on

Code: Select all

cBuffer:= Buffer( 4096 )

easily changed to

Code: Select all

#ifdef __XSHARP__
cBuffer := Space( 4096 )
#else
cBuffer := Buffer( 4096 )
#endif

The next error

Code: Select all

error XS9035: The first argument to PCall must be a 'typed function pointer'.

on

Code: Select all

PCall( ptrFunction, @strWinOsVersionInfo )

was changed to

Code: Select all

#ifdef __XSHARP__
PCallNative<int>( ptrFunction, @strWinOsVersionInfo )
#else 
PCall( ptrFunction, @strWinOsVersionInfo )
#endif

Next series of errors:

Code: Select all

error XS0246: The type or namespace name '_GCDUMP' could not be found (are you missing a using directive or an assembly reference?)

in a function that dumped the current memory for diagnosis. Since the .NET garbage collector is totally, different, I decided to remove the entire function by adding an #ifndef __XSHARP__ before and a #endif after.
The same proceeding was used then on the error

Code: Select all

error XS0619: 'Functions.Memory(int)' is obsolete: ''Memory()' is not supported'

Next (and last error for this article):

Code: Select all

error XS0619: 'Functions._VOLoadLibrary(string)' is obsolete: ''_VOLoadLibrary()' is not supported, use VulcanLoadLibrary() instead.'

repeated several times on various dynamic loads of DLLs:

Code: Select all

hDLL := _VOLoadLibrary( cDLLName )
if hDLL == null_PTR
  ErrBox( oWindow, StrTran( 'library %1 not found", "%1", cDLLName ) )
  return false
else
  hProc	:= GetProcAddress( hDLL, String2Psz( "CPPlusInitDLL" ) )
  if hProc == null_ptr
    ErrBox( oWindow, "error on initialization" =
    return false
  endif
  PCall( hProc )                                                             
  if IsClass( #ZipClass )
    lRetCode := true
  else
    ErrBox( oWindow, "error on initialization of " + cDLLName )
    return false
  endif
endif

Since this code cannot work with X# as .NET works in a completely different manner, and DLLs are to be loaded with Reflection, I decided to not implement this for the moment, so my code was changed to:

Code: Select all

#ifdef __XSHARP__
ErrBox( oWindow, "error on initialization of " + cDLLName )
return false		// TODO 
#else
... remainder of code
#endif

[wriedmann]

Hello,

since the writing of this posts is very time consuming, please don't expect posts in too short periods.

At the same time, I will prepare a PDF that has not only the same content as these posts, but will be kept updated and enhanced, adding better explanations where needed. An example would be the different behavior of the VO garbage collector and the .NET one: .NET calls always the destructor, whereas in VO you need to register for it with RegisterAxit()

Thank you very much to Chris Pyrgas for pointing this out!

Wolfgang

[Chris]

Hi Wolfgang,

Thanks a lot for posting your experience with porting and for explaining the actions and changes you had to make to your code to compile it in X#. I think such information is very helpful, so others will be also prepared about what they will need to do when they also port their apps.

It is also very rewarding for us devtem members to see that our efforts have paid off, it's great seeing and hearing more and more about VO apps that have been already ported to X#. And yes, we will be further improving the procedure in the coming builds.

Chris

[wriedmann]

Hi Chris,

I'm very surprised how you guys have done a such compatible compiler (ok, sometimes the error messages could be better or more precise ). The VO language and runtime are very different from other development systems, and they allowed us programmers to be very productive. The .NET environment may have several of these things already (like the garbage collector), but there are a lot of specialities remaining.

My base library may be a good example for very old code (its origins are in the pre-release of VO 1.0 under Windows 3.1) and several constructs that are simply not allowed in a .NET language and even some pieces of code that should never have compiled even in VO.

And I have to say that the major part of adjustments were to make in my base library - the other libraries and the Dictionary Editor needed only very few adjustments. And I have started to use the X# version of the Dictionary Editor in my daily VO development.

Wolfgang

[wriedmann]

Hi,

if someone is awaiting the next post: I'm currently working on a (more extensive) version of the first 3 articles in PDF format, and I hope to publish the next article tomorrow, together with the relative PDF version (that contains more background information and will be kept up to date).

Wolfgang

[wriedmann]

Hi,

since I need to move my application often, I have added a function to my XIDE plugin: Tools - Copy application folder name.
This function copies the name of the application folder name to the clipboard so you can paste it in the VO xPorter output folder input control.

In the attached zip you will find both the sources (you need to change the references to your own XIDE path if you wish to compile itself) and the executable (simply copy to the XIDEPlugins directory and restart XIDE).

Wolfgang