I'm trying to get this simple program to work on windows, but it crashes:
unsigned (__stdcall testfoo)(ClientData x)
{
return 0;
}
int main()
{
Tcl_ThreadId testid = 0;
Tcl_CreateThread(&testid, testfoo, (ClientData) NULL, TCL_THREAD_STACK_DEFAULT, TCL_THREAD_NOFLAGS);
}
I am using a makefile generated by cmake and linking against a version of Tcl 8.5.7 I compiled myself using Visual C++ 2008 express. It was compiled using msvcrt,static,threads and the name of the resulting library is tcl85tsx.lib. The error is:
Unhandled exception at 0x77448c39 in main.exe: 0xC0000005: Access violation writing location 0x00000014.
The Tcl library works fine, and I can even run a threading script example by loading the Thread extension into it. My assumption is that there is something horribly wrong with a memory violation, but I have no idea what. Any help appreciated.
TclInitSubsystems is called when you call Tcl_FindExecutable(), which is public. If you don't have the executable name to hand, just pass NULL there.
I ended up compiling a debuggable version of Tcl. The issue is that you need to call TclInitSubsystems to initialize all the locks required for thread creation. Unfortunately, this isn't publically accessible, and an intepreter needs to be created with Tcl_CreateInterp. This was a test program for an application I was developing that has a Tcl interpreter, so it will not be an issue in production. I just need to create an interpreter for this simple test program.
Related
I am using Flutter to develop a Windows program, Need to disable input method, Find the relevant documentation, you can use the ImmDisableIME(0) method to disable the input method. But when I try to call this method, An exception was reported when running the project.
main.cpp
win32_window.cpp
How to properly disable the input method?
An exception was reported when running the project
No. An exception was not reported when running the project. Rather, your program never ran to begin with because it had a compiler error.
Because you are passing -1 to a function expecting an unsigned integer (DWORD), the compiler is warning you (C4245). And your build environment treats warnings as errors (C2220).
To invoke it with -1 such that it disables for all threads in the current process, then invoke it as follows with a cast. It's as easy as that.
DWORD dwParam = (DWORD)(-1);
ImmDisableIME(dwParam);
I am trying to compile C++ code to wasm and then embed it in other C++ code with wee8 (v8's wasm-api). Currently I'm getting a Segfault on instantiating the module:
auto instance = wasm::Instance::make(store, module.get(), imports);
Note that I have no problem embedding code that I write as .wat and convert to .wasm, so the problem is specifically with embedding code compiled with emcc.
I am guessing that what I'm missing is WASI support in wee8? Does it exist? How can I enable it? Alternatively: can I ask emcc not to generate any WASI calls?
Here is a minimal example which results in:
Process finished with exit code 139 (interrupted by signal 11: SIGSEGV)
In cpp42.cpp:
int main() {
return 42;
}
Compiling this to wasm with:
emcc -O3 cpp42.cpp -o cpp42.wasm
Inspecting the compiled wasm module with wabt's wasm2wat shows that it contains the following import
(import "wasi_snapshot_preview1" "proc_exit" (func (;0;) (type 0)))
Which I suspect to be the cause of the problem.
Then embedding with wee8 like in the examples in the repo and like I do with other wasm files causes the segfault mentioned above.
Just as another check: running
wasmer cpp42.wasm
echo $?
> 42
Works without a problem.
I can answer part of your question:
I'm missing is WASI support in wee8? Does it exist?
No, wee8 does not implement WASI. Adding such support is theoretically possible, but not currently scheduled to get done.
You can implement it yourself in your wee8 embedder, and make it available to loaded modules via imports. Most (or all?) of it could probably be a reusable (among many engine implementations) library, potentially offered and maintained by the WASI project itself. (I don't know whether such a library exists already.)
You didn't say what imports object you're currently passing; it needs to be an array of wasm::Extern* pointers that's at least as long as the imports of the module, and ordered equivalently (i.e. imports[i] will be the module's ith import).
(I agree that the Wasm C/C++ API is very barebones currently. Unless/until that is changed, you'll have to build any convenience mechanisms yourself. It's all possible with the information that's available, it's just clearly less convenient than instantiating Wasm modules from JavaScript.)
I have a question, I came across running an x86 app on XP x64 that throws up a couple (2) of the "The application has failed to start because XYZ.DLL was not found". My question is, it still runs fine! So how does that work? I know if some function is missing you get that and the app doesn't actually run. What causes this message yet it runs fine? I don't think LoadLibrary() would put up a message? Is it from some #pragma comment( lib, "XYZ.lib" ) in a library even if that module not used?
TIA!!
My question is, it still runs fine! So how does that work?
If a DLL function is statically linked and can't be found at runtime, the OS will fail to create and run the process at all. So, the obvious answer is that the DLL function is linked dynamically instead via calls to LoadLibrary() and GetProcAddress() at runtime.
I know if some function is missing you get that and the app doesn't actually run.
If the missing DLL function is linked statically, yes.
What causes this message yet it runs fine? I don't think LoadLibrary() would put up a message?
Actually, it can. Use SetErrorMode() to avoid that. This is stated as much in the LoadLibrary() documentation:
To enable or disable error messages displayed by the loader during DLL loads, use the SetErrorMode function.
See Silently catch windows error popups when calling LoadLibrary().
Is it from some #pragma comment( lib, "XYZ.lib" ) in a library even if that module not used?
Linking to a DLL's .lib creates static linkage to the DLL. Unless the linker has a delay-load feature available AND the project is making use of that feature, in which case any static calls to the lib's referenced DLL functions are converted into runtime calls to LoadLibrary()/GetProcAddress() by the compiler+linker for you.
I have a C API DLL we created for a USB product we make that I thought would be nice to be able to import with python without using any wrapping functions like ctypes. Our DLL is already statically linked with boost and the C runtime for other functionality without any problems. Once I add any exported python functions such as this simple test:
#include <boost/python.hpp>
char const* greet()
{
return "hello, world";
}
BOOST_PYTHON_MODULE(mymodule)
{
using namespace boost::python;
def("greet", greet);
}
The DLL that gets built now depends on python34.dll at load time. Normally this would be fine, but the reality is that most users of our DLL currently aren't going to use the python functionality. What I would like to happen is to only have this dependency if the module gets loaded by python, or when a python function gets called for the first time. That way only python users would need to have the python DLL, and our DLL would not get an error loading on systems that lack the python DLL when not being loaded by python code.
On solution I can think of would be to create a separate DLL just for python users that either calls our DLL or includes all of its functionality. I would prefer to just have one binary if possible though. Once there are two or more files involved I question the value over just distributing a wrapper written in python using ctypes.
In my own Windows C/C++ code, I always load whatever DLLs I can on-demand so that I can do better error reporting to the user and maybe allow the program to run with crippled functionality if it is not there. I was a little surprised that boost.python was pulling in python34.dll right at load time.
Apologies in advance for the following verbose question ; I am a COM noob.
Scenario: I need to call a managed DLL built with C# from native Visual C++ code. In my native VC++ code, I do the following after registering "SomeDLL.dll" and generating the "SomeDLL.tlb" file with RegAsm.exe.
Import the TLB file with #import "SomeDLL.tlb"
Use the class MyClass defined in the DLL with CComPtr<MyClass>.
Everything's great! It compiles, and I can run the code etc. It hits the fan when I try to run this application on a different machine (i.e. not the one I compiled it on). I copy all the required DLLs, and I register the same DLL with RegAsm.exe but it doesn't work.
It specifically fails when it tries to initialize the COM library with CoInitialize(0) and returns the S_FALSE error which means
The COM library is already initialized on this thread.
I can confidently state that I have not called this function anywhere else in my code.
Any suggestions?
Hard to help you find that code from here, you're a lot closer. Maybe a DLL that gets injected.
Getting S_FALSE is not an error, getting RPC_E_CHANGED_MODE would be quite bad. Be sure to use the FAILED macro:
HRESULT hr = CoInitialize(0);
if (FAILED(hr)) {
CallNineOneOne(hr);
exit(hr);
}
Maybe you called OleInitialize or another function which calls ComInitialize behind the scenes.
Anyway, it does not matter to call CoInitialize several times per thread if you match each of them with a call to CoUninitialize