[CONNECT Update 12 C] 'native C' migration from V8i

Hello,

I am on a migration project from V8i (native C) to CONNECT.
Different messages found on different forums are not clear for me...
The existing project is composed of 50000 lines of code - native C.
My goal is to minimise the changes to complete the migration.
==> The main question is "are native C projets still supported with CONNECT edition ?"

It seems that the migrate tool is *just* a string remapping from old V8i/C to CONNECT/C++.
For example, the constant 'UNIT_ANGLE_Radians' is remapped by 'StandardUnit::AngleRadians'
Surely this kind of syntax cannot be compiled in C file (but in a C++ file).
How can I use this tool if I want to stay in native C ?

It seems that the provided makefiles are not working with .C extension files.
The following message is displayed when the source file is a .C one : "This file is for C++ compilands only"
Is there a way to use those makefiles (with a define or someting) or are there specific makefiles available ?
 
On the other hand MicroStationCONNECTSDK\include\Mstn\MdlApi contains the needed .H (and .FDF) files with the 'C' functions prototypes.
For example 'mdlScan_initialize()' defined in msscan.fdf found in V8i SDK and CONNECT SDK.
So to me it must be a way keep using those old 'native C' API... No ?

Thanks a lot, Pascal.

  • Hi Pascal,

    Different messages found on different forums are not clear for me...

    For several years, there is only this MicroStation Programming forum, plus BDN forum (that should be used for BDN specific discussions). Any other "MicroStation programming" forum is probably obsolete and not containing the latest topics.

    Despite of few years old, the most complex overview of migration topics is MicroStationCONNECT_MigrationWorkshop.pptx delivered with MicroStation SDK.

    What can be confusing a bit is that the migration in fact consist from several different tasks:

    • Migration from V8i API (which is both C and C++) to CONNNECT Edition API (strongly type C++).
    • Migration from C++ 8.0 (Visual Studio 2005) to C++ 14 (Visual Studio 2017).
    • Migration of the code itself to changed MicroStation functionality exposed by the API.
    The existing project is composed of 50000 lines of code - native C.
    My goal is to minimise the changes to complete the migration.

    To minimize changes is valid target, but because it has to be migrated to new API, some amount of changes is always required. How big the change should be (50 000 is still smaller C project) depends how code structured and how tightly it depends on MicroStation API. My experience is that in some situations it makes sense to rewrite substantial portions of original code, whereas in some others, mostly mechanical substitution changes are enough.

    The main question is "are native C projets still supported with CONNECT edition ?"

    I think will be able to provide better and more detailed answer, but in my opinion the answer is "no". MicroStation CE API is strongly typed C++ API, so you have to compile your code as C++ (.cpp extension) and to modify the code accordingly to API requirements. On the other hand, the most of C code is also valid C++ code (this is technically complicated topic, depending also on used C/C++ compiler ;-), so the first step in the migration is about to rename .c to .cpp.

    It seems that the migrate tool is *just* a string remapping from old V8i/C to CONNECT/C++.

    Yes, it's exactly what the tool does: It saves some time and effort helping rename code where 1:1 remap rule exists. Nothing more, not rewriting the code to work with the new API ;-)

    For example, the constant 'UNIT_ANGLE_Radians' is remapped by 'StandardUnit::AngleRadians'

    Yes, and the reason is explained in PowerPoint I mentioned above: It's about more strict API, when C-style using macros and int constants (which cannot be checked by compiler for a validity) were changed to enums (not available in C).

    How can I use this tool if I want to stay in native C ?

    What exactly do you want and why? Do you want to use something like "pure C compilation", which I guess is not simple even in Visual Studio (and not supported by MicroStation API), or to write C code (with C++ constructions where it's required by MicroStation API) that is later compiled as C++?

    It seems that the provided makefiles are not working with .C extension files.

    It's correct finding. MicroStation API is C++, so it's expected source files will use .cpp extension (the same expectation as Visual C compiler use).

    So to me it must be a way keep using those old 'native C' API... No ?

    I am not sure, but based on my C++ dev knowledge (which is currently worse than C# and NET Framework knowledge), it's not possible and I see no reason why to try to hack the prepared ecosystem for such functionality. There is a new API available in MicroStatio CE, providing much better functionality, plus more restricitve (strongly typed) API leads to better code. Why to try to find workaround to use it in a different way?

    With regards,

      Jan

  • So to me it must be a way keep using those old 'native C' API... No ?

    I am not sure, but based on my C++ dev knowledge (which is currently worse than C# and NET Framework knowledge), it's not possible and I see no reason why to try to hack the prepared ecosystem for such functionality. There is a new API available in MicroStatio CE, providing much better functionality, plus more restricitve (strongly typed) API leads to better code. Why to try to find workaround to use it in a different way?

    Yes it is possible, because C is a still a subset of C++. You could formally change your makefiles, etc. from C to C++. It works.

    But is it wise? Even if you do so, and rename everything with the migration tool, I would guess your fulfillment would be at optimistic 5% - 10%.

    I would recommend to take your time, analyse your code and functionality, and then  decide wicht part could be migrated, and for what part ist would be easier (less working-time => less cost) to create new.

    Mit freundlichen Grüßen / Best regards
    Volker Hüfner

    |  AB_DATE Engineering  Software   |  ab-date.de  |

  • the constant 'UNIT_ANGLE_Radians' is remapped by 'StandardUnit::AngleRadians'
    Surely this kind of syntax cannot be compiled in C file

    The C++ MicroStationAPI makes extensive use of namespaces, classes, smart pointers and templates, all of which are alien to C.

    I want to stay in native C

    That's a bad strategy.  We've been able to use C++ to write more functional, more concise, more readable, more reliable and higher performance applications than MDL since MicroStation V8 2004 Edition.  That was fifteen or more years ago.  But keep in mind that the ISO C++ standard is compatible with ISO C.

    it must be a way keep using those old 'native C' API

    Since MicroStation V8 2004 Edition, new functionality has been provided by the MicroStationAPI.  For example, the valuable GraphicElementEnumerator class has no MDL analogue.  Expect MDL to diminish while the MicroStationAPI grows.

    Much of MDL/C relied on complex macros and 'magic numbers'.  The MicroStationAPI eschews that style of secret programming in favour of a well-designed interface.

    For example 'mdlScan_initialize()'

    The mdlScan_api is an example of a horrible C interface.  Its use depends on a set of complex macros to select element types, and extensive bit-twiddling to choose levels.  Its design emulated Intergraph's hardware DGN file scanner, which was a physical bolt-on to the mini-computers used by their customers.

    With the MicroStationAPI, you can more simply enumerate elements.  You can abandon the mdlScan_api, although you might occasionally find a need to use its better-designed descendant, the mdlScanCriteria_api.

     
    Regards, Jon Summers
    LA Solutions

  • Good evening

    Thank you very much for the full and fast answers.

    First I don't doubt it is a good idea to follow the evolution imposed by the connect ecosystem (C++ and so on).
    Unfortunately rewriting with new API and new language means understand what the code does and then rewrite (and optionaly optimize) it with C++.
    My knowledge is much higher in C programming than in CAD :-)
    So if the migration consists in mechanical substitutions it's fine for me.

    Concerning the MicroStationCONNECT_MigrationWorkshop.pptx
    May be want I to read and understand only what would please me, but page 91, I can read that 'MDL C API (native)' is a supported platform (also page 42).
    OK it's the third choice but if it is still working, it's fine for me ;-). 

    I want to be 100% sure rewriting is C++ this is the only way to migrate.
    If so, the planning and the needed resources to complete this project won't certainly be the same !!

    Thanks again, Pascal

  • Hi Pascal,

    I can read that 'MDL C API (native)' is a supported platform (also page 42).

    I think it's not ideal formulation. In my opinion your can use "pure C" concepts (no own classes, functions only) as long as you will be compatible with API, which is strongly typed C++ (so the code has to be compiled as C++). Because I have had no reason, I have never checked new API whether any "C only" parts exist.

    I am sure is able to provide more details as he lead the workshop.

    I want to be 100% sure rewriting is C++ this is the only way to migrate.

    My feeling is that several different options with different level of complexity are mixed in this discussion:

    What is required is to make your code compatible with the new API. Technically it means to use C++ constructions where it's required by API, which is mostly about replacement of old macros by strongly typed enums and similar modifications (methods names...). Even this step can require a lot of work, but mostly mechanical. On the other hand, when the code is old, a substantial part of necessary modifications are not because of new C++ API, but because of new compiler is more strict and does not accept old code.

    What is recommended (but not mandatory) is to remove old C constructions and replace it with new, better and more robust, classes. It's what Jon and Volker recommend (I agree, scanning in C is complicated, today iteration is simple), but it should be second optional step in my opinion, because without perfect knowledge what the code does it will be quite risky.

    My knowledge is much higher in C programming than in CAD :-)

    You will need somebody with MicroStation knowledge anyway, at least from these reasons:

    • MicroStation CONNECT Edition is very different from V8i, especially in GUI, so it has to be evaluated whether old application (GUI, dialogs etc.) can be used in new GUI to do not make users too much confused.
    • The code functionality, especially when the application has long history, should be analysed for an overlap with existing MicroStation tools. I remember one migrated (not very complex) application, where we were able to remove about 50% of the code because the same functionality exists now in MicroStation. To make the transition as simple as possible, the application GUI remained the same (old toolboxes), but standard MicroStation tools were called at background.
    If so, the planning and the needed resources to complete this project won't certainly be the same !!

    The migration may require a huge amount of work, especially when code is old, undocumented and poorly written. It's hard to guess upfront. But for sure it's not about "recompilation only".

    With regards,

      Jan

  • It seems that the provided makefiles are not working with .C extension files

    Rename *.c to *.cpp. C++ is a superset of C, so the compiler will recognise the file type and understand its contents.

    Keep in mind that all the #include files (*.h, *.fdf) are in new folders, and the compiler won't be able to find them until you run the *.cpp files through the project migration tool.

     
    Regards, Jon Summers
    LA Solutions

  • Hi ,

    Please note that Jan, Volker and Jon's input on this thread to this point are certainly all relevant, helpful and spot on to help set perspectives accordingly.

    Granted MicroStation CONNECT is certainly one of the most highly updated versions we have released to date; prior significant updates including: MicroStation V8 and MicroStation/J releases.  There are certainly a lot of new product features, workflows, customization and programming options and capabilities to learn and assess and almost a necessary/required first step for any user, administrator or developer; before trying to migrate and re-build a customization without such considerations.  Maybe not the best analogy but another way to think of migration in general (I certainly think this often related to migrating items): Am I building a different (inferior) version of an Existing or already Improved Wheel, or is a Wheel even necessary or even Fit (in) anymore (with a given new product workflows, UI, etc.)?

    MicroStation CONNECT does provide many new and improved APIs (and target programming languages and supported environments) to consider and I recommend all developers having customizations take a bit of time to review some current information available in the order presented to ensure a proper and productive path migrating starting here:

    Developers and Programming > Migrating to CONNECT

    Lastly, although ideally we would like far fewer (user, admin and developer) steps needed to advance to CONNECT; on the development side, we do envision a very long, active and productive 64-bit product incremental development release cycle. An incremental release cycle primarily offering stability and productivity improvements and not likely to have further (future) significant major development release impacts impacts migrating to: MicroStation CONNECT, MicroStation V8, or MicroStation/J editions.

    I hope the above information helps and as you have further questions please do feel free to Search and Ask questions on this forum and it's very helpful community.

    HTH,
    Bob



  • Surely we mut find a MS-consultant to complete the CAD part of it - not so easy in France

    How about Europe?

     
    Regards, Jon Summers
    LA Solutions