I'm working on a C++ .dll plugin that gets passed UE4 classes like FName, UClass, FPlatformTime, etc for a game that I do not have the source code of. I would like to access the passed objects and view/modify their class members in my plugin.
Adding UnrealEngine\UE_4.25\Engine\Source\Runtime\Core\Public as additional include directory and then including #include "UObject/NameTypes.h" in my source file results in a seemingly endless amount of missing defines in headers like Build.h, Platform.h.
What is the correct way to include the UE4 classes in a simple Visual Studio C++ project without using the editor?
I've compiled a small UE4 project and I'm currently using the UE4 class headers extracted from its .pdb as the output is simple enough but I'd like to use the proper UE4 headers.
Inside the UE4 solution, take a look at various programs, such as "BlankProgram" and "SlateViewer". These use UE4 modules and are built using UnrealBuildTool, but you could create your own program and only link to the UE4 modules that you need. This will effectively let you create a lightweight program without unneeded stuff such as UMG or media players, for example.
One downside to this is that, due to how UnrealBuildTool works, your program must reside inside the engine's "Source/Programs" folder and follow a simple, but non-negotiable template (i.e. it needs to have a <YourProgram.Target.cs> file where its type is set to "Program").
Best of luck!
Unreal Engine types are meant to be used with Unreal Engine, they are not designed to be used in a pure C++ project outside of the Unreal Engine ecosystem.
My Dart package is currently laid out in the following manner:
lib/
mypackage.dart
src/
mypackage_util.dart
test/
mypackage_test.dart
Inside mypackage.dart, I'm using the part, part of import strategy to use
mypackage_util.dart in mypackage.dart, as recommended by the Pub Layout
conventions.
On the test side, I took inspiration from Seth Ladd's example of using
unittest,
which shows him creating a new library for his tests, which makes sense to me.
Unfortunately, this leads to the inability to import mypackage_util.dart into
mypackage_test.dart, which means I can't test classes or functions from
mypackage_util.dart, or anything in src/.
The solutions I'm imagining are;
Make mypackage_test.dart a part of the main library, but this seems to make
it impossible to just run the test code stand-alone.
Take mypackage_util.dart out of src/, but this seems to imply that you
can never unit test src/ code in packages, which seems silly and exposes
code I don't want to.
Should I take one of the above approaches, or am I missing something?
Update:
The above situation was due to a library import conflict (see Chapter 2. Dart Tour's Libraries and Visibility section for solutions to library conflicts). See comments below.
If lib/mypackage.dart declares the library and includes lib/src/mypackage_util.dart using part/part of you just need to include lib/mypackage.dart in your test - or is your problem that you want to test private classes/functions contained in lib/src/mypackage_util.dart?
Is it possible to call a C/C++/Python/Java function that makes an HTTP request inside of a Verilog module?
Yes, do some searching for 'DPI' or 'PLI'. If you have a SystemVerilog capable simulator the DPI solution is a lot less overhead. Basically the Verilog end of it will be:
import "DPI" function void do_http(...)
Where you can then call do_http within your Verilog like a normal task or function and you pass the .c file that implements do_http on the command line along with the rest of your sources. This of course is assuming that you're using a commercial Verilog simulator. I don't think Icarus supports DPI yet (could be wrong).
Using VPI is a more portable but takes significantly more coding to put together. I encourage you to research that one on your own if that's what you need.
I'd like to unit test a gen_fsm that uses a fairly large record for its state. The record is defined within the erl file that also defines the gen_fsm and thus is not (to my knowledge) visible to other modules.
Possible approaches:
Put the record into an hrl file and include that in both modules. This is ok, but spreads code that is logically owned by the gen_fsm across multiple files.
Fake a record with a raw tuple in the unit test module. This would get pretty ugly as the record is already over 20 fields.
Export a function from my gen_fsm that will convert a proplist to the correct record type with some record_info magic. While possible, I don't like the idea of polluting my module interface.
Actually spawn the gen_fsm and send it a series of messages to put it in the right state for the unit test. There is substantial complexity to this approach (although Meck helps) and I feel like I'm wasting these great, pure Module:StateName functions that I should be able to call without a whole bunch of setup.
Any other suggestions?
You might consider just putting your tests directly into your gen_fsm module, which of course would give them access to the record. If you'd rather not include the tests in production code, and assuming you're using eunit, you can conditionally compile them in or out as indicated in the eunit user's guide:
-ifdef(EUNIT).
% test code here
...
-endif.
I'm using two commercial libraries that are produced by the same vendor, called VendorLibA and VendorLibB. The libraries are distributed as many DLLs that depend on the compiler version (e.g. VC7, VC8). Both libraries depend on a another library, produced by this vendor, called VendorLibUtils and contained in one DLL.
The problem: VendorLibA uses a different version of VendorLibUtils than VendorLibB. The two versions are not binary compatible, and even if they were it would be a bad idea to use the wrong version.
Is there any way I could use the two libraries under the same process?
Note: LoadLibrary can't solve this since my process is not that one that's importing VendorLibUtils.
EDIT: Forgot to mention the obvious, I don't have to source code for any of the commercial libraries and probably I will never have (sigh).
EDIT: The alternative btw, is to do this: How to combine GUI applications in Windows
I think your most promising option is to complain, loudly, to the vendor who is distributing mutually incompatible products. That rather goes against the idea of a DLL.
You can't just put the DLLs in different directories. Once a DLL with a given name is loaded, all other attempts to load another DLL with the same module name will simply use the one that's already loaded, even if the paths are different.
From that, we can conclude that to load two copies of VendorLibUtils, one copy needs to have a different name. You can't just rename the DLL file; the code in your program won't know to look for the different file. Therefore, perhaps there's a way to edit the import table of VendorLibB to make it think the functions it needs are in VendorLibUtilsB.dll instead of just VendorLibUtils.dll. I'm afraid I don't know of any utility that will do that, but I have little doubt it's possible to do.
I had a similar problem. Specifically I wanted to use a PyQt from a Python interpreter embedded in an application that was using an incompatible version of Qt. There were two Qt DLLs used by the primary application: QtCore.dll and QtGui.dll.
When I would load PyQt from the embedded Python interpreter, I would get an error:
ImportError: DLL load failed: The specified procedure could not be found.
This occured on the line:
from PyQt4 import QtGui
The problem is that the once an incompatible QtGui.dll is loaded into the main application's process space any references to QtGui.dll (e.g. from the file QtGui.pyd) are incorrect.
What happened next, I am not proud of.
First I renamed QtGui4.dll in the PyQt distribution to QtGuiX.dll
and then renamed the QtCore4.dll to QtCoreX.dll. Notice that the
renaming maintained the same number of characters, this is important.
Next I opened the file QtGui.pyd in Notepad++, and replaced all
plain-text references of QtGui4.dll to QtGuiX.dll and from
QtCore4.dll to QtCoreX.dll. I repeated the process for the files:
QtCore.pyd, QtGuiX.dll and QtCoreX.dll.
Finally I checked that my PyQt test application still worked. It did!
Then I tried running the PyQt test application from the embedded
Python interpreter, and it worked as well.
So, it seems to works in a couple of trivial cases. I expect that I
need to repeat the process for all DLLs and PYDs in the PyQt
distribution.
This is probably not the right way to do things, but I can't think of any concrete reasons how it could blow up (other than if I change the length of the file name).
Credit (or blame) to others on the thread for inspiring this terrible tale.
As someone else mentioned, you could rename one of the copies of VendorLibUtils and modify the import table of the associated VendorLib DLL to link to it, rather than the VendorLibUtils.dll it was created with.
There's a few tools out there that let you edit EXE/DLL files in this way. CFF Explorer is a pretty decent one which allows editing of the import table. If you open up the VendorLib DLL in it and go to the Import Directory section (in the tree on the left), you'll see a list of modules at the top of the main window. You can rename the module by double-clicking on its name. Then you just save the DLL and it should now use your renamed VendorLibUtils DLL.
Of course, this assumes that VendorLib uses the import table to access VendorLibUtils, which it may not -- it may use LoadLibrary/GetProcAddress, in which case you won't see an import table entry for VendorLibUtils.
Actually, if the VendorLib does use the import table but also uses LoadLibrary to access the VendorLibUtils DLL in some places (I've seen it done), those places will still use the wrong one. If you rename both libraries, you might at least see an error if this is the case (since a DLL with the original name won't exist now). There is a way to deal with this if it occurs, but it starts to get quite complicated at this point, so I won't elaborate unless you really want/need to know.
As you are not using VendorLibUtils directly, I assume you can't use LoadLibrary etc.
If the VendorLibUtils DLLs only have exports by ordinal, you could probably rename one of the the libraries and patch the corresponding VendorLibX to use a different filename for its imports.
If the VendorLibUtils DLLs have one or more exported symbols with the same names, you might need to patch the imports and export tables too, but let's hope not! :-)
I'm no expert in DLLs, but the only way I see it possible would be to use LoadLibrary() and explicitly load the DLLs. Then you could place the functions/classes etc in separate namespaces using GetProcAddress().
HMODULE v1 = LoadLibrary(_T("libv1_0.dll"));
libv1_0::fun_in_lib = reinterpret_cast<FUNTYPE>(GetProcAddress(v1, _T("fun_in_lib"));
and
HMODULE v2 = LoadLibrary(_T("libv2_0.dll"));
libv2_0::fun_in_lib = reinterpret_cast<FUNTYPE>(GetProcAddress(v2, _T("fun_in_lib"));
Whether this would work or not still kind of depends on the library, so it may or may not work, but as far as I can tell it's the only possibility.
You mean, you have a situation similar to MSVCRT80.DLL and MSVCRT90.DLL ? There is a good reason Microsoft numbered these DLLs.If both were called MSVCRT.DLL, only one of them would be loaded in a single process.
It is actually possible to implicitly load different versions of a dll into a single process.
Doing this entails:
Creating two assemblies, each containing a version of the dll that must be loaded multiple times. Sounds complicated but practically it entails little more than creating (2) named sub folders, each with a .manifest file containing some xml, and its own copy of the dll. So, VendorUtilsAssemblyV1 and VendorUtilsAssemblyV2
Making each dependent dll use the assembly mechanism to resolve the implicit dependency - by adding a assemblyDependency directive that explicitly identifies VendorUtilsAssemblyV1 or V2.
There are some options for point 2. If the VendorLibA and VendorLibB files do not contain their own manifests, then you can simply add manifest files with the required dependentAssembly directive named VendorLibA.2.dll.manifest and VendorLibB.2.dll.manifest.
If they already contain manifests (probably to link to the VS2005 or VS2008 C-Runtime) then use the MT.EXE tool to merge in the new dependency.