I created an .MA application and corresponding dll using Visual Studio 14.0.
When launching MicroStation CE version 10.16.00.80, I specify a specific configuration (-wu<config>) on the command line which contains the entry MS_DGNAPPS indicating that my application should be loaded at startup.
Works great.
So far, so good.
On a different PC, I have the very same version of MicroStation but at startup it gives me error 193 (the OS could not load myappl.dll).
I did some googling and this error should indicate that I'm trying to load a 32 bit DLL, which is not true (I checked it with DUMPBIN /HEADERS).
Within MicroStation I tried to load the MDL manually (Ribbon Design/Utilities/MDL applications). It does show me my custom applications but when trying to load one of them, I get the very same error.
I'm quite sure I'm missing something stupid but I can't figure out what it is.
Thanks,
Robert
Hi Robert Kock,
MicroStation CONNECT (and respective SDKs) Update 12 thru 16 require Microsoft Visual Studio 2017 (MSVC 14.1) vs. VS2015 (MSVC 14.0). Ref: MicroStation CONNECT SDK Requirements.
Do you notice the issue if re-compiling with the required VS 2017?
It is worth noting in the near future when MicroStation CONNECT Update 16.1 releases Microsoft Visual Studio 2019 (MSVC 14.2) will be the default toolset required.HTH,Bob
Hi Robert,
Thanks for your reply. I'll check it out and be back to you.
The question is: how come everyting does work on the PC on which I compiled everything?
Robert Kock said:I was wrong when I said I compile with VS 14.0. It appears to be VS 2019 version 14.16.27023.
Visual Studio 2019 is not supported (but will be in CE Update 16.1). You have to use Visual Studio 2017.
There is a way, how to use VS2019, but it requires to be MSVC and Visual Studio guru to ensure the right toolset (MSVCRT verison) is used, and also modification of mki file(s) is necessary. Probably there is no serious reason why to choose such way.
Robert Kock said:Below find the installed versions on the PC that works
I agree with Jon the problem is caused probably by wrong (or missing) version of MSVCRT. When the right tools are used, the problem does not exist, because both MicroStation and Visual Studio compiler use the same MSVCRT.
Robert Kock said:Below find the installed versions on the PC
I can see you use MicroStation SDK CE U14 with MicroStation CE U16. Are you serious about such development style?
For every MicroStation version, proper SDK version was released. Exceptions existed, but it's not the case of U16, where SDK CE U16 is available.
When you prefer to use C++ to create native applications for MicroStation, to follow strict rules about used tools and their versions is mandatory. Otherwise the result is not predictable and unstable. To combine some version of MicroStation with another SDK, in parallel to unsupported Visual Studio version, just cannot lead to robust result.
With regards,
Jan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
When creating my development environment, I simply installed the latest version of VS. I'll try to uninstall VS2019 and install VS2017.
MS CE Update 16 was installed when the Connection Client suggested me to do so. I didn't know about SDK update 16.
I'll start from scratch and see what happens.
Thank you so far
I got various versions of Windows SDK on my PC. Can I simply uninstall them after having uninstalled VS 2019? Does the installation of VS 2017 include the correct version of Windows SDK?
Robert Kock said:I got various versions of Windows SDK on my PC. Can I simply uninstall them after having uninstalled VS 2019? Does the installation of VS 2017 include the correct version of Windows SDK?
Those are questions for a Microsoft support site. We're happy to advise about MicroStation development on this Forum, and there are many more people on other Forums who like to discuss Viz Studio and the Windows SDK.
Regards, Jon Summers LA Solutions
Robert Kock said:When creating my development environment, I simply installed the latest version of VS.
honestly, I do not understand the logic. When I want to develop anything in any language, using any tool, the first thing is to check and follow prerequisites exactly (regardless it's MicroStation using C++ or iTwin.js using TypeScript). It's never like "just to install the latest version", even in a case of such flexible environment like NET ... and especially not in the case of C/C++, famous because of problems with MSVCRT versions and "dll hell".
Robert Kock said:I'll try to uninstall VS2019 and install VS2017.
There is no reason to uninstall VS2019, when used for another projects. I typically have 2 or 3 versions installed in parallel, of course not as full installations (because it does not makes sense and consumes too much space), but in configurations containing what I need for active projects.
Because I use VS2019 for all NET development, I typically use it as editor for C++ code also. When such code is compiled using bmake, VS2017 (C++ compiler/linker) is used automatically, so no compatibility problem exists.
Robert Kock said:MS CE Update 16 was installed when the Connection Client suggested me to do so.
It's automatic, no exceptions: When new MicroStation version is installed and you want to develop application for such version, you have to reinstall SDK also.
When new MicroStation or MicroStation SDK is released, it's announced in MicroStation Announcements forum, so there is no obstacle to be informed when a pair Microstation + SDK is available.
Robert Kock said:I'll start from scratch and see what happens.
When new MicroStation SDK is installed, it's always recommended to try to compile (all) delivered examples and to test some, to test everything is installed and set correctly.
Robert Kock said:I got various versions of Windows SDK on my PC. Can I simply uninstall them after having uninstalled VS 2019?
It's up to you, whether you need them or not.
Robert Kock said:Does the installation of VS 2017 include the correct version of Windows SDK?
I am not sure what do you mean by "correct version of Windows SDK". "Correct" for what? If you mean "for MicroStation", I recommend to check SDK release announcement, where required VS parts are mentioned, Also, what is necessary from Visual Studio installation was discussed several times in this forum, so use search.
When you need any specific version of Windows SDK for other project than MicroStation, it makes sense to install it independently from Microsoft archive, because Windows SDK is independent completely. Visual Studio should be able to recognize the installation automatically (even when maybe does not work when the latest SDK and old VS combination is used).
Regards,
I'm mainly a Java programmer in a Unix environment and not used to the strict dependencies of Windows and/or C++.
You're never too old to learn
Robert Kock said:I'm mainly a Java programmer
In such context, to use C# would be "more friendly way" because of many similarities with Java. But, in MicroStation, NET API is a bit more limited than C++ (but no so much), on the other hand it offers WPF GUI, rich environment and one from the best dev tools available.
Robert Kock said:in a Unix environment and not used to the strict dependencies of Windows and/or C++.
Yes,that's often discussed question why Microsoft did not use some concept from shared libraries and other ideas, known at the time, when dlls were invented.
Fortunately, because C++ has been back in a main Microsoft focus for last few years, and is developed actively now (including ISO standardization), new MS C++ compilers and MSVCRTs solve the compatibility problem partially. Technically it's possible now to use VS2019 to compile native dll exactly as it was in VS2017, maintaining compatibility, but it requires good knowledge how the system works.
But in the case of MicroStation, when you do not want to invest time into own research and creating own environment, leading to maybe correct and compatible result, but still not supported officially, it's simpler to use standard supported tools (including bmake, which a lot of people do not like, but that does a lot of tasks and settings automatically).
Robert Kock said:You're never too old to learn
Tell me about it :-) My recent trip from "always desktop" to "web systems" and learning things like Node.js, JavaScirpt, TypeScript and some popular frameworks is just challenging :-))))
OK, I uninstalled VS 2019 and installed VS 2017. Made the necessary changes in the *.vcxproj file and recompiled everything.
Made sure that the various installations on the source and target machines are perfectly aligned.
Unfortunately, I get the very same result: error 193 when loading my application.
I got 1 very serious doubt: on my target machine I have also MicroStation V8i SS10 installed (for legacy reasons; we're still porting everything). Could that influence the behaviour?
Thanks again,
Robert Kock said: on my target machine I have also MicroStation V8i SS10 installed (for legacy reasons; we're still porting everything). Could that influence the behaviour?
MicroStation CONNECT is a 64-bit app., MicroStation V8i is a 32-bit app. Bentley Systems tells that it is OK to have both versions installed on the same computer. The app. Registry data lives in separate parts of the Windows Registry.
Do you have any Windows environment variables set that could confuse things? For example, does MS (if you have it defined) point to the CONNECT version of MicroStation?
MS
My development computer has had both versions installed with no problems, and I'm sure that others can confirm that.
Robert Kock said: at startup it gives me error 193 (the OS could not load myappl.dll)
Where have you put your app. (which folder) on the other computer? What version of MicroStation CONNECT (or other product) is installed on that computer?
Robert Kock said:Unfortunately, I get the very same result: error 193 when loading my application.
I agree with Jon that to check Windows and MicroStation configuration makes sense, but to know the application code may help too:
In .ma source code (.r), how DllMdlApp structure is defined? It points to .dll file that should be loaded. Is it possible that it points to another dll (another name) file? Or, as Jon mentioned, configuration variables are set in such way, that another (e.g. some older) version is loaded (even though I assume the file from the same folder should be loaded first).
Also, because, as you mentioned, error 193 is typically mentioned in relation to 32 / 64bit dll mismatch, is it possible there is also 32bit version of the same dll available?
Hi Jan/Jon,
First of all, thank you so much for your effort. Though the problem is still not resolved, you're doing everything to help me.
My target machine:
Windows 10 Pro, version 21H1, build 19043.1165
Processor AMD Ryzen 5 5600U, 2.30GHz
16GB RAM
Microstation Connect Edition, version 10.16.0.80
I got the variable $MS point to CE and not to V8i.
The script that launches MS contains the line:
start %MS%microstation.exe -wdoracle -wusigra-it %SIGRA%\data\logosigra.dgn
The %SIGRA% points to the root directory of all my files, including all custom .ma and .dll
The logo-DGN is opened correctly at startup
When I rename the dll, putting an underscore in front, I get error "Cannot find myappl.dll" (or something similar, I got the Italian version). So, MS is trying to load the correct dll.
I double checked by means of the VS utility DUMPBIN and the DLL is actually 64 bit.
In myappl.r, I defined:
#define DLLAPP_MYAPPL 1
DllMdlApp DLLAPP_MYAPPL ={ L"myappl", L"myappl"}
I searched the whole harddisk of the target machine and there's no other file with the same name.
My development machine:
Windows 10 Pro, version 20H2, build 19042.1165
Processor Intel Core i7-10510U, 2.30GHz
Personally, I don't think that the Windows build and/or type of processor make any difference.
I'm quite sure I made a very stupid error or have overseen something very obvious.....
Robert Kock said:The %SIGRA% points to the root directory of all my files, including all custom .ma and .dll
What is the definition of MicroStation configuration variable MS_MDLAPPS?
MS_MDLAPPS
In the user's configuration file, we got, among others, the following entries:
Where %SIGRA% equals C:\SirenCE
My CE custom applications are found in C:\SirenCE\so_nt\apps\italiano
It seems everything is pointing to the correct directories
Robert Kock said:MS_SETTINGSDIR = $(SIGRA)/data MS_MDLAPPS < $(SIGRA)/so_nt/apps/italiano MS_LIBRARY_PATH < $(SIGRA)/so_nt/apps/italiano MS_MDL < $(SIGRA)/so_nt/apps/italiano
If those are defined in a configuration file, then you must append a slash (/) to each folder path. Without the trailing slash, MicroStation tries to interpret the value as a file specification.
MS_SETTINGSDIR = $(SIGRA)/data/ MS_MDLAPPS < $(SIGRA)/so_nt/apps/italiano/ MS_LIBRARY_PATH < $(SIGRA)/so_nt/apps/italiano/ MS_MDL < $(SIGRA)/so_nt/apps/italiano/
Or, easier to maintain...
SIGRA_ITALIANO = $(SIGRA)/so_nt/apps/italiano/ SIGRA_INGLESE = $(SIGRA)/so_nt/apps/english/ SIGRA_LANGUAGE = $(SIGRA_ITALIANO) MS_MDLAPPS < $(SIGRA_LANGUAGE) MS_LIBRARY_PATH < $(SIGRA_LANGUAGE) MS_MDL < $(SIGRA_LANGUAGE)
Hi Jon,
In my previous reply I made an error during copy/paste: within the configuration file all directory entries already have a trailing slash.
By the way, within the reply I manually resolved some environment variables.
The real entry is:
MD_MDLAPPS < $(SIGRA)/$(SISTEMA)/apps/$(LINGUAGGIO)/
Where:
$(SISTEMA) equals "so_nt" and
$(LINGUAGGIO) equals "italiano"
Robert Kock said:Where %SIGRA% equals C:\SirenCE
Given that %SIGRA% should instead equal C:/SirenCE/
Jon Summers said:Or, easier to maintain... SIGRA_ITALIANO = $(SIGRA)/so_nt/apps/italiano/ SIGRA_INGLESE = $(SIGRA)/so_nt/apps/english/ SIGRA_LANGUAGE = $(SIGRA_ITALIANO) MS_MDLAPPS < $(SIGRA_LANGUAGE) MS_LIBRARY_PATH < $(SIGRA_LANGUAGE) MS_MDL < $(SIGRA_LANGUAGE)
Your suggestions ought to be written as:
SIGRA_ITALIANO = $(SIGRA)so_nt/apps/italiano/SIGRA_INGLESE = $(SIGRA)so_nt/apps/english/SIGRA_LANGUAGE = $(SIGRA_ITALIANO)MS_MDLAPPS < $(SIGRA_LANGUAGE)MS_LIBRARY_PATH < $(SIGRA_LANGUAGE)MS_MDL < $(SIGRA_LANGUAGE)
Barry Lothian said:Given that %SIGRA% should instead equal C:/SirenCE/
We don't know. There may be other reasons why SIGRA — a Windows environment variable — should not have a trailing slash. The rules of MicroStation configuration variable definition should not be applied to Windows environment variables without testing.
SIGRA
Barry Lothian said:Your suggestions ought to be written
I don't know about ought. They could be written without a slash after $(SIGRA) if that were to be redefined as you advise.
$(SIGRA)
Robert Kock said:I made an error during copy/paste: within the configuration file all directory entries already have a trailing slash
So this discussion is moot.
I'm not sure if it may help, but I hereby attach the output of DUMPBIN /HEADERS /DEPENDENTS of the DLL.
So far, I've always referred to the DLL as "myappl" while its actual name is "SHD_LIBRARY". It is loaded at startup and exports tons of functions used by other customer applications.
Its MdlMain, after some general initialization, launches a second application that executes the login procedure.
Microsoft (R) COFF/PE Dumper Version 14.16.27045.0 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file C:\Develop\SIREN-INP\CAD_CE\rilascio\SIGRA-IT\so_nt\wind\apps\italiano\shd_library.dll PE signature found File Type: DLL FILE HEADER VALUES 8664 machine (x64) 6 number of sections 61250C25 time date stamp Tue Aug 24 17:11:33 2021 0 file pointer to symbol table 0 number of symbols F0 size of optional header 2022 characteristics Executable Application can handle large (>2GB) addresses DLL OPTIONAL HEADER VALUES 20B magic # (PE32+) 14.16 linker version 1C1000 size of code 43FFA00 size of initialized data 0 size of uninitialized data 1BB67C entry point (00000001801BB67C) _DllMainCRTStartup 1000 base of code 180000000 image base (0000000180000000 to 00000001845C4FFF) 1000 section alignment 200 file alignment 6.00 operating system version 0.00 image version 6.00 subsystem version 0 Win32 version 45C5000 size of image 400 size of headers 0 checksum 2 subsystem (Windows GUI) 160 DLL characteristics High Entropy Virtual Addresses Dynamic base NX compatible 100000 size of stack reserve 1000 size of stack commit 100000 size of heap reserve 1000 size of heap commit 0 loader flags 10 number of directories 244830 [ 5FA4] RVA [size] of Export Directory 24A7D4 [ 190] RVA [size] of Import Directory 45C3000 [ F8] RVA [size] of Resource Directory 45B7000 [ B1E4] RVA [size] of Exception Directory 0 [ 0] RVA [size] of Certificates Directory 45C4000 [ 7B0] RVA [size] of Base Relocation Directory 22A770 [ 70] RVA [size] of Debug Directory 0 [ 0] RVA [size] of Architecture Directory 0 [ 0] RVA [size] of Global Pointer Directory 22A8E0 [ 28] RVA [size] of Thread Storage Directory 22A7E0 [ 100] RVA [size] of Load Configuration Directory 0 [ 0] RVA [size] of Bound Import Directory 1C2000 [ 1360] RVA [size] of Import Address Table Directory 0 [ 0] RVA [size] of Delay Import Directory 0 [ 0] RVA [size] of COM Descriptor Directory 0 [ 0] RVA [size] of Reserved Directory SECTION HEADER #1 .text name 1C0F0D virtual size 1000 virtual address (0000000180001000 to 00000001801C1F0C) 1C1000 size of raw data 400 file pointer to raw data (00000400 to 001C13FF) 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 60000020 flags Code Execute Read SECTION HEADER #2 .rdata name 8E02C virtual size 1C2000 virtual address (00000001801C2000 to 000000018025002B) 8E200 size of raw data 1C1400 file pointer to raw data (001C1400 to 0024F5FF) 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 40000040 flags Initialized Data Read Only Debug Directories Time Type Size RVA Pointer -------- ------- -------- -------- -------- 61250C25 cv 6F 0022C3BC 22B7BC Format: RSDS, {E84A2B0D-BB33-4FC4-B598-252FFC915B9B}, 1, C:\Develop\SIREN-INP\cad_ce\rilascio\SIGRA-IT\so_nt\wind\apps\italiano\shd_library.pdb 61250C25 feat 14 0022C42C 22B82C Counts: Pre-VC++ 11.00=0, C/C++=118, /GS=118, /sdl=85, guardN=33 61250C25 coffgrp 338 0022C440 22B840 4C544347 (LTCG) 61250C25 iltcg 0 00000000 0 Image has the following dependencies: KERNEL32.dll USER32.dll OCI.dll USTATION.dll Bentley5.dll BentleyAllocator.dll DgnPlatform5.dll RmgrTools3.dll BentleyGeom5.dll MSVCP140.dll VCRUNTIME140.dll api-ms-win-crt-string-l1-1-0.dll api-ms-win-crt-convert-l1-1-0.dll api-ms-win-crt-stdio-l1-1-0.dll api-ms-win-crt-heap-l1-1-0.dll api-ms-win-crt-runtime-l1-1-0.dll api-ms-win-crt-time-l1-1-0.dll api-ms-win-crt-environment-l1-1-0.dll api-ms-win-crt-math-l1-1-0.dll SECTION HEADER #3 .data name 4365B38 virtual size 251000 virtual address (0000000180251000 to 00000001845B6B37) 2800 size of raw data 24F600 file pointer to raw data (0024F600 to 00251DFF) 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers C0000040 flags Initialized Data Read Write SECTION HEADER #4 .pdata name B1E4 virtual size 45B7000 virtual address (00000001845B7000 to 00000001845C21E3) B200 size of raw data 251E00 file pointer to raw data (00251E00 to 0025CFFF) 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 40000040 flags Initialized Data Read Only SECTION HEADER #5 .rsrc name F8 virtual size 45C3000 virtual address (00000001845C3000 to 00000001845C30F7) 200 size of raw data 25D000 file pointer to raw data (0025D000 to 0025D1FF) 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 40000040 flags Initialized Data Read Only SECTION HEADER #6 .reloc name 7B0 virtual size 45C4000 virtual address (00000001845C4000 to 00000001845C47AF) 800 size of raw data 25D200 file pointer to raw data (0025D200 to 0025D9FF) 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 42000040 flags Initialized Data Discardable Read Only Summary 4366000 .data C000 .pdata 8F000 .rdata 1000 .reloc 1000 .rsrc 1C1000 .text
Robert Kock said:Image has the following dependencies
Are those DLLs all present on the non-working computer?
I hardly dare to admit, but I forgot to install the 64bit version of the oracle client.
Things are workly correctly now.
Thank you so much and sorry I wasted your time.
Answer Verified By: Robert Hook