I have a dll that uses boost Asio for networking. When I link this dll to an application running on Windows 2000, a runtime exception is thrown:
"The procedure entry point freeaddrinfo could not be located in the dynamic link library WS2_32.dll"
Microsoft provides a workaround at http://msdn.microsoft.com/en-us/library/ms737931(VS.85).aspx, but that did not work for me.
Can anyone point me to a solution??
Thanks a lot,
-- Vijay
Are you building your dll with the correct values set for NTDDI_VERSION and _WIN32_WINNT to target the Windows 2000? You want them set to 0x05000000 and 0x0500. Assuming you then rebuild your dll completely you should then either get a warning about the compiler not being able to find freeaddrinfo (if you haven't followed the MS workaround) or it should 'just work'.
Right now I expect you're building to target a later version of windows and the headers are allowing you to use the function which isn't present in the system dlls that are present on the system that you're trying to run on.
Related
Good day,
I have an application that I developed that transfers files between two machines ("site" and "server"). This application was set to target dotNet 3.5. Furthermore, I am using Renci.SshNet to handle the connections between the machines and the transferring of said files.
The issue that I am facing currently though is that about 70% of the "site" machines do not have a standard dotNet and is also quite old; thus these machines do not support all the required functionality as the external dll makes calls to System.Threading.WaitHandle.WaitOne() and System.Threading.WaitHandle.WaitAny(WaitHandle[], Int32) and other overloads of these methods.
The workaround that I have for this though is to install netfx20SP2 or netfx30SP1, yet I am not in the position to perform this update on all machines as they are scattered across the country and have data limitations (bandwidth and cap).
What I want to do possibly is to embed the System.Threading dll that I have downloaded and then the application should use those classes instead, or alternatively just point the application to use the said dll.
Is this at all possible, or do you have to load the dll into the GAC? And also, will it be possible to "run" this higher version of System.Threading in the application while the system itself is on a lower framework version. Something is telling me that the best bet will be to actually run the service pack installation to avoid unnecessary coding but I'm not sure exactly how to approach this.
Thank you in advance for any assistance / suggestions,
JD
To allow the execution of an application that, let's say, targets .Net 4; while the machine itself only has let's say, .Net 3.5, installed, one can redirect Windows to check the local (executing) directory for dlls that should contain the required symbols loaded into memory instead of the default symbols that get loaded upon execution (the default would be the NetFx installed on the machine - which I believe the highest version of the framework that can be found upon loading when the execution starts or would be the highest available version that is lower or equal to the targeted framework).
This file's contents (myApp.exe.local) are ignored. It is just there to tell Windows to
look in that folder for the applicable symbols and if not found, the system will roll back to attempt to load these symbols from the NetFx directory.
Read more at Microsoft Dev Center - Docs (link is attached to the following paragraph which is a Copy-Paste of a section of this document).
To use DLL redirection, create a redirection file for your application. The redirection file must be named as follows: App_name.local. For example, if the application name is Editor.exe, the redirection file should be named Editor.exe.local. You must install the .local file in the application directory. You must also install the DLLs in the application directory.
I'm new to C++ and Allegro 5 but have been able to follow tutorials online and am able to build and compile several smaller projects successfully.
I cannot however get the demo project named Cosmic Protector to run and would like to at least learn what is wrong.
Unfortunately, I can't give you much to go on.
A window opens briefly and then closes, leaving the console open with the message..
process 6400 exited with code 255
If you have this demo running in VC 2017 with the latest release of Allegro 5 (5.2.4) installed via Nuget, I'd like to know that even.
The source for this program is available at...
https://github.com/liballeg/allegro5/tree/master/demos/cosmic_protector
Thank you, Jack
The allegro example programs and demos are usually built with CMake alongside the Allegro library. I just tested the CMake build of Allegro 5 with VS2017 on Windows 10 and it builds the Cosmic Protector demo successfully. You have to move the allegro dlls into the same directory as the exe, but other than that it runs perfectly.
As to why it's not working for you, cosmic protector depends on a data directory that holds it's resources. The working directory may be wrong, which would cause it to be unable to find resources. The data dir needs to be copied alongside the executable.
You can set the working directory to $(OutDir) under Debugging in Project->Properties and then it should find any data in the same directory as the exe.
How are you building cosmic protector?
Thanks to BugSquasher, I now have this working.
Here's how...
Start Visual Studio 2017
Create New Project of type Windows Console Application.
Name project CosmicProtector and save it in appropriate place on my HDD.
Disable precompiled headers and delete the any .h and .cpp
files associated with the new project regarding precompiled headers.
(for example pch.h)
Install Allegro 5.2.4 via Nuget.
In Visual Studio, navigate to Project Settings/Properties and ensure all
Allegro addons are enabled.
Copy the Cosmic Protector SRC and Header files and paste them into my
project directory.
Next in Visual Studio Project, Add the Source and Header files
respectively.
Rather stupidly, the step I had missed and that your reply brought my attention to was...
Copy the data directory and paste this into my project directory in the
applicable location.
Now build...
The project built right away, except for some errors reported in Game.cpp, GUI.cpp and Render.cpp
One error in Game.cpp, this being an instance of...
error C4996 'snprintf': This function or variable may be unsafe. Consider using snprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS.
To address this I have changed the instance of snprintf to sprintf_s.
Three errors in GUI.cpp, were instances of...
Error C4996 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS.
To address all of these I changed each instance of strcpy to strcpy_s.
And one error in GUI.cpp, this being an instance of...
error C4996 'snprintf': This function or variable may be unsafe. Consider using snprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS.
To address this I have changed the instance of snprintf to sprintf_s.
One error in Render.cpp, this being an instance of...
error C4996 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS.
To address this I have changed the instance of sprintf to sprintf_s.
Then build and it works:)
Thank you so much for your reply as I had moved on to other things but will find it very useful I think being able to build and run this demo.
It's only your reply that has brought me back to it and this time, I am successful:)
I have installed pycparser that parses C code.
Using pycparser I want to parse an open source project, namely PostgreSQL(version-11.0). I have build it using Visual Studio Express 2017 compiler suite. However, during compilation it cannot find some header files, namely windows.h and winsock2.h.
While looking at the directory structure of the build PostgreSQL, I find that it does not have these header files. How to fix this issue?
Also a strange error occurred as:
postgresql/src/include/c.h:363:2: error: #error must have a working
64-bit integer datatype
Note: I am using Windows 10 64-bit platform and postgresql-11.0
The steps are as follows:
I downloaded visual studio 2017, Windows-10 SDK, Active Perl as described in the steps to build from source in PostgreSQL.
After this I open the developer command prompt of Visual Studio and navigate to the folder postgresql-11.0/src/tools/msvc
Use command "build" to build postgresql. The build process was successful, but still windows.h and winsock2.h was not found in directory structure of PostgreSQL.
I don't know pycparser, but your problem probably has two aspects to it:
You didn't give pycparser the correct list of include directories. The header files you mention are not part of PostgreSQL.
Maybe you can get the list from the environment of the Visual Studio prompt. I don't have a Windows here to verify that.
The error message means that neither HAVE_LONG_INT_64 nor HAVE_LONG_LONG_INT_64 are defined.
Now pg_config.h.win32, which is copied to pg_config.h during the MSVC install process, has the following:
#if (_MSC_VER > 1200)
#define HAVE_LONG_LONG_INT_64 1
#endif
Since you are not using MSVC, you probable don't have _MSC_VER set, which causes the error.
You could define _MSC_VER and see if you get to build then.
Essentially you are in a tight spot here, because pycparser is not a supported build procedure, so you'll have to dig into the source and fix things as you go. Without an understanding of the PostgreSQL source and the build process, you probably won't get far.
I have these error messages when I start MS-Access application (has VBA code).
When I click OK in the first error message and debug in the second, the debugger opens up and points to the line that says: "Set oServer = New SQLDMO.SQLServer"
I realise that it's a problem with SQL-DMO, but can't seem to register the DLL.
My environment: Win7 Pro 64-bit, Office 2010 64-bit, MS SQL Server 2008 R2 SP2 64-bit.
I downloaded the backwards compatibility package from Microsoft, ran the MSI, and nothing.
Tried to manually install, and get error messages:
R6034 for C:\Windows\System32\regsvr32.exe and when I click Ok --> The module "SQLDMO.DLL" failed to load. Make sure the binary is stored at the specified path or debug it... blah blah
When I try to register it from C:\Windows\SysWOW64, I get "The module "SQLDMO.DLL" may not (be) compatible with the version of Windows that you're running. Check if the module is compatible with....
I've checked the version of SQLDMO.DLL and it is definitely 64-bit. I have located all the other DLLs that SQL-DMO needs and stored them in SysWOW64 and System32.
I have run Office repair, Windows Update, SQL Server repair (the log file indicates pass for everything for Client Tools Backwards Compatibility).
Any help is much appreciated.
Thanks, Miki.
Not sure how I've managed to, but have (somehow) managed to register the 64-bit SQLDMO.DLL (before it didn't really register it) and then in my VBA code--> Tools --> References... I tried to load the SQLDMO.DLL from the 64-bit folder.
At first, it didn't work, and then I placed a copy of the DLL in SysWOW64 (which is a 32-bit folder) and registered it from there (once it was registered, apparently, the system doesn't need it there anymore - I removed it, and it still works).
I then tried to figure how come it works. I checked in the Reference Table in the VBA Code, and the Microsoft SQLDMO Object Library is still pointing to C:\Program Files (x86)\Microsoft SQL Server\80\Tools\Binn, but when I removed SQLDMO.DLL from there it still worked... I then looked in C:\Program Files\Microsoft SQL Server\80\Tools\Binn and removed SQLDMO.DLL from there and then it stopped working!
I have no idea what happened, or why the reference table is saying it's pointing to one folder but actually pointing to a different one, or how after the same tries before, only now it works.
I'd like to be able to replicate this (in case I need to go through this process again), so any ideas/suggestions would be greatly appreciated.
Thanks, Miki.
Running Ubuntu Oneric 11.10 with 1 GB RAM and 250 GB HDD Dell Inspiron Laptop.
I got some demo code from a tutorial to read XML. When I compile it, I get this message:
"The type or namespace name '.Xml' does not exist in the namespace 'System'. Are you missing an assembly reference?" (using System.Xml;)
I have the library in this path: /usr/lib/mono/gac/System.Xml/4.0.0.0_b77a5c561934e089/System.Xml.dll
Are you using MonoDevelop to build your application? If so, make sure that there is a reference to System.Xml in your project.
In case you are hardcore enough to "manually" use dmcs to build your application (or you are using a Makefile or some other automated build process), make sure you pass /r:/usr/lib/mono/4.0/System.Xml.dll as one of the arguments to your dmcs build command.
Only for didatic purposes, here is the references editing option in MonoDevelop, in which you should choose to add a reference:
Note: your distro could have installed System.Xml.dll in another path, so please verify.
Your monodoc problem is an entirely different issue and probably means either a directory or file is missing from the installed docs or there is a bug in monodoc entirely