v8i and VS2005

v8i - so i have inherited this system when i took this job in April. version is 08.11.09.459 and sdk version 08.11.09.357

I was told at the time that i could only use vs 2005 to update any of the code. Please advise if i should be able to use anything newer

Parents
  • Hi Steven,

    version is 08.11.09.459 and sdk version 08.11.09.357

    For MicroStation V8i 08.11.09.459, MicroStation SDK 08.11.09.460 was released.

    The SDK version 08.11.09.357 you mentioned was released for previous MicroStation version, so you should update your SDK (even when it's probably not critical in this case).

    I was told at the time that i could only use vs 2005 to update any of the code.

    Yes, for all V8i versions (08.11.09..xx), Visual Studio 2005 Professional is the only officially supported VS version.

    Please advise if i should be able to use anything newer

    No. The newer VS versions are used to compile native code for MicroStation CONNECT Edition.

    With regards,

      Jan

  • Thanks Jan for the quick response... 

    as for the using VS 2005 - what is the reason we have to use it?  Why have they (Bentley) not kept up with newer technology?

    We are moving to Connect and i currently use vs2017.

    Thank you again for the help

    Steve

  • as for the using VS 2005 - what is the reason we have to use it?

    The reason is what is usually called "DLL hell": When you link native dll files in Windows, you have to use (simplified formulation) the same compiler for all dlls. And because MicroStation V8i was built using VS 2005 (or at least its main part and public API), all API consumers have to use also VS 2005.

    More precise and detail answer is that you have to ensure C runtime version, namely because of allocating and freeing memory. In the past, every Visual Studio (better to say every VisualC++ compiler) was released with own C++ runtime (well known msvcrt.dll files and vcredist installers).

    Skilled C/C++ developers (I do not treat myself as such developer) can use different versions, because there are some practices how you can access "runtime borders", but in some cases it's really not possible (e.g. when API request it will allocate memory, but you have to deallocated it yourself).

    Why have they (Bentley) not kept up with newer technology?

    It's internal decision, but why they should do so. To migrate to newer tools also represent some transition cost. In the case of so complex product like MicroStation, consisting internally from different technologies, the cost can be enormous ... with questionable benefits.

    And in fact, Bentley did it, but in a form of CONNECT Edition: The first MicroStation CE was released 5 years ago (oh... that cannot be true ;-), if I remember right, testing with limited testers were done about 2 years before public release, and the development was started few years before testing was started. So Bentley moved to newer compilers about 10 years ago probably, but (wisely) kept V8i as is to do not break what was tuned and debugged for many years.

    BTW Microsoft made the migration and C runtime compatibility better in last versions of Visual Studio (I guess it was in 2015?), so the migration to newer versions is faster and smoother now.

    With regards,

      Jan

Reply
  • as for the using VS 2005 - what is the reason we have to use it?

    The reason is what is usually called "DLL hell": When you link native dll files in Windows, you have to use (simplified formulation) the same compiler for all dlls. And because MicroStation V8i was built using VS 2005 (or at least its main part and public API), all API consumers have to use also VS 2005.

    More precise and detail answer is that you have to ensure C runtime version, namely because of allocating and freeing memory. In the past, every Visual Studio (better to say every VisualC++ compiler) was released with own C++ runtime (well known msvcrt.dll files and vcredist installers).

    Skilled C/C++ developers (I do not treat myself as such developer) can use different versions, because there are some practices how you can access "runtime borders", but in some cases it's really not possible (e.g. when API request it will allocate memory, but you have to deallocated it yourself).

    Why have they (Bentley) not kept up with newer technology?

    It's internal decision, but why they should do so. To migrate to newer tools also represent some transition cost. In the case of so complex product like MicroStation, consisting internally from different technologies, the cost can be enormous ... with questionable benefits.

    And in fact, Bentley did it, but in a form of CONNECT Edition: The first MicroStation CE was released 5 years ago (oh... that cannot be true ;-), if I remember right, testing with limited testers were done about 2 years before public release, and the development was started few years before testing was started. So Bentley moved to newer compilers about 10 years ago probably, but (wisely) kept V8i as is to do not break what was tuned and debugged for many years.

    BTW Microsoft made the migration and C runtime compatibility better in last versions of Visual Studio (I guess it was in 2015?), so the migration to newer versions is faster and smoother now.

    With regards,

      Jan

Children
No Data