Is it technically possible (I don't think this would be restricted), and how do you go about it?
I got my little test app building fine, but when I run it I get a failure dialog.
The debug output is slightly more informative:
The thread 0xe4c has exited with code -1073741515 (0xc0000135).
The program '[3400] OpenCVTest2.exe' has exited with code -1073741515 (0xc0000135) 'A dependent dll was not found'.
Then I created a Win8 Desktop app, which also built fine but failed to run.
MSVP100D.dll is part of the VC++ 2010 Redistributable which is not compatible with Win8. (Being a hacker I tried it anyway, the installer runs to completion - but the bits aren't installed.)
Is there a compiler flag I can try? Possibly a custom build of OpenCV would fix it, but that would be a last resort, and it might only fix the desktop app.
This guy shows an example of using OpenCV library for performing face detection in a Windows 8 Store app written using C++/CX:
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/DEV322
Also, at the below post he also describes how the C++ Runtime works for Windows 8Store apps:
http://blogs.msdn.com/b/vcblog/archive/2012/09/28/10354327.aspx
MSVP100D is not a part of VC10 redist. Note the "D" at the end of its name. That package only includes release builds. Your release builds should work fine. But mixing libraries from different VC versions might get you in trouble. See this. Your best chance is to build from source with VC11.
Related
Update: It turned out that there was something with installing Delphi 10.4 CE that broke my app (thanks, DelphiCoder!); specifically, it was something in the Windows Registry that was broken. After using ProcessMonitor to ensure no Delphi 10.4 (aka 21.0) was being invoked, I ended up cleaning out the registry of all 10.4 references, rebuilding completely (not clear if this was needed or not), and lo and behold, it works again! I'm adding this update in case someone in a similar situation finds this question - remember to back up your registry first and be careful!
Original Post: I created several DLLs with Matlab Compiler 10 years ago, with C wrappers, to make them available with Delphi. Once I got them working, they always worked - until today! The code in the C wrapper initialization function in question is in the code box below; the "Could not initialize library" is printed to the console when I run my Delphi app.
mclmcrInitialize();
if (!mclInitializeApplication(NULL, 0)) {
fprintf(stderr, "Could not initialize application\n");
}
if (!libMyDllInitialize()) {
fprintf(stderr, "Could not initialize library\n");
}
The problem is that this has never happened before, over all the probably 10 years since we first wrote these! My machine has the correct version of the 32-bit 2021a MCR installed, as it has for several years; I've installed this on numerous machines from Windows XP up to Windows 10, The DLLs were last built 5 - 7 years ago; anyway, I don't have access to the Matlab compiler anymore. The only thing that has changed is my app, but not anywhere near where this DLL initialization code is called; also, when the problem first happened, my app was working, then didn't -without any changes. Finally, I went back a few days and rebuilt my app, and it still fails.
So I am really stuck, and need some advanced help in debugging DLL startup issues on Windows. I tried looking in the Windows Event Logger, but nothing appears to show up there. Logs to check? A setting in the Registry that somehow got hosed? Wrong phase of the moon? How does one debug loading/initializing a formerly working DLL when forced to treat it as a black box? Help!
How does one debug loading/initializing a formerly working DLL [...]?
I think there is no definitive answer to your question.
This is how we have gone about debugging the loading/initializing of DLLs and applications and may help you:
We regularly work with systems where we have no source code for the DLLs (and often we don't have any source code for the applications either). We experience DLL conflicts quite regularly. When testing why applications don't start as expected we have found the use of Sysinternal's Process Monitor by Mark Russinovich invaluable.
This will show you system level activity. You can filter for your process and then you will see all file, registry, thread and network activity (although thread and network are quite limited). If the DLL has dependencies then the system tries to find those and so you will be able to discover all dependent DLLs and COM interfaces (by seeing the registry lookups for that interface) that it's looking for. Process Monitor will show if the resource is not found or if access is denied.
Slightly more difficult to discover is if one of the dependencies exists but the export table has changed (so the functions have different signatures or export ordinals). There are ways to check that (by looking at the export and import tables) but generally (if you have access to a working environment) it's enough to check the filesize, timestamp (and the VERSIONINFO resource if there is one) between DLLs.
I would like to open F# compiler solution (FSharp.sln) from https://github.com/fsharp/fsharp/ in an IDE on a mac, then make some changes and run the compiler or ideally step through the code.
I tried JetBrains Rider, but it gets stuck soon after opening the solution: "Initial file processing: prim-type-prelude.fs". Code completion is not available.
I also tried opening another solution from https://github.com/Microsoft/visualfsharp, but both Rider and Visual Studio For Mac crash almost immediately.
What's the best way of working on F# compiler source code on a Mac? Is this feasible only on Windows? I'm new to .net and F#.
Edit: I had much better luck with Windows and Visual Studio. Everything worked pretty much out of the box. I was able to run the project, debug selected test and make minor changes with code completion enabled. I might be missing something, but it seems like it's a much smoother experience on Windows than on a Mac.
I'm trying to make an ActiveX control for an application on a Windows CE 6.0 device, but I can't get it to register on the device. When I transfer the .ocx file over to the device and try to register it using regsvrce.exe, it fails with error 7e, which I've learned means a dependency is missing. How can I identify which dependency is missing? Alternatively, have I gone about creating the ActiveX control wrongly?
I have loaded the .ocx in Dependency Walker on my development machine (running Windows 7 64-bit, if that matters) and all of the top-level dependencies it lists are present on the CE device. I can't check further down the tree since Depends then looks for the top-level dependencies on my development machine, half of which are missing since they're CE-specific. Dependency Walker doesn't run on the CE device (unless there's a CE version I've missed?). I tried to copy the DLLs from the CE device to a flash drive so I could load them into DW on my development machine, but the device won't allow me to do so. The OEM tool I have for transferring files unfortunately only transfers to the device. [Edit: I haven't tried writing my own tool to try to pull files from the device to development machine.]
Some details on how I've set up the project, in case I have some wrong assumptions on that end. I have tried with two projects. One has my code in it (the ActiveX Control itself is just a graphical representation of some data, which I had originally set up in a win32 ActiveX control to see how it looks), and one is a clean project - created from template, compiled, downloaded to device; no code added or configuration changed. Both have the same result when trying to register.
Using VS2005, created a project using the "MFC Smart Device ActiveX Control" template, targeting the SDK I received from the OEM.
In the case of the project with my code in it, I copied my drawing code into the project and created the necessary properties for the data input. I can provide more details on my code if it would help, but my issue happens even without the code. I am assuming that since it compiles successfully when targeting the SDK from the OEM that the functions I am using are supposed to be available on the target device.
Build the project in Release configuration (I wondered if the debug libraries were missing on the target device and causing the issue).
Transfer the .ocx file to the target device using an OEM tool.
Start command line on target device, move to directory the .ocx is in, run "regsvrce.exe .ocx". I have also tried transferring all of the files that VS leaves in the build output folder, but the result is the same.
Many thanks in advance for any answers! If you see something obvious point it out - this is my first ActiveX project and my first CE project, so it's very possible I'm missing something basic.
Since you build OCX I assume that you are using MFC. How do you link with MFC? Look in project settings|General, try to select "Use MFC in a Static Library". Same goes for ATL - try selecting "Static Link to ATL" (if you use ATL). This goes also for VCRT - in C/C++|Code Generation, in "Runtime Library" try selecting options without the 'DLL' (i.e. - statically link with VCRT).
Since the default empty OCX does not work for you - this is the only thing I can think of...
Another thing - I assume you have a reason for working with Visaul Studio 2005? Why not a newer version?
Good luck, PazO
I'm interested in playing around with the MaxSAT/MaxSMT c example (specifically, maxsat.c) provided on the z3 (Microsoft Research) website. Using Visual Studio 2010, I eventually got the example to compile (using a fresh install of z3 4.0). However, I can't get any of my (SMT 2.0) models to run using them. Further, I cannot get the example posted in this question to work either.
In the first case, my compiled program crashes when it tries to call Z3_get_smtlib_num_formulas in get_hard_constraints of the file. I don't know why, instead, I get the standard windows 7 "this program has stopped working" popup.
In the second case, it reports unsupported ;benchmark.
In order to help me to get this work, I was wondering if
(a) Has anyone had similar issues when compiling this code, and if so, how did you resolve them?
or
(b) How can I debug either compilation of the file (assuming it is correct)? Namely, can someone enumerate the correct libraries (and library versions - e.g., z3 4.0?) to include in the compiler options to get this example working?
In either case, information on the error reported in the second case would also be appreciated: what does it mean exactly? The keyword was not valid? That the SMT input is the wrong version? Or something else?
Thanks.
The MaxSAT example has not been updated to SMTLIB 2.0 yet. It uses the function Z3_parse_smtlib_file to parse the input, which means that it supports only SMTLIB 1.0 at the moment.
This example is distributed alongside Z3, i.e., you should have received a copy in Z3-4.0/examples/maxsat/, which also contains compilation and execution scripts.
Compilation should be straight-forward by running build.cmd in a Visual Studio Command Prompt, or build.sh on Linux.
I am interested in trying to get a program ported to 64-bit and would like to know if it's even a good candidate for porting. I am a lighting director and have built a SUSE 11.1 Linux box for a program called MagicQ made by Chamsys (http://www.chamsys.be/download.html). I have been working on this for about 6 months now and have all hardware recognised. I am still working on stage visualizers, and I have a separate CPU/board generating the DMX512 code via PoE. I don't think getting it to run in SUSE will be a problem "it was natively built for Ubuntu".
Any help or direction is greatly appreciated!!
Unbuntu and Suse are subtlely different in how things are laid out for file sytems, home directories and such. Usually when you try to install a package on either on you need to use their own package manager programs so that all dependincies are handled and you don't need to manually try to find package 'x' version 'y' and package 'a' version 'b' just to get something working.
If you know that you have all the dependencies covered, and if you have the raw source code, you should be able to just run a compilier against the source code and have it compilied for a 64-bit processor.
Here is a link to the GCC, the GNU Compiler Collection for your reference.
Good luck with your porting project.