I create four CAsynSocket Classes in four CwinThread classes When I first create them Socket (with notification events) bind ioctl, setsockopt. I follow the CASynSocket::Socket call to sockcore.cpp and
has a valid Hwnd Value. The context of the creation of sockets in the CwinApp after my main CFrameWnd has been created.
I then start a conversation with the server (connect send and then receive). It is at a point that I would like to give the work over to a modeless dialog. this is where things go wrong. After getting a message
from the server I try to do a detach which goes to
Since I was debugging this in release mode I never got the subsequent assert on this.
First off in the documentation for CAsynSocket there is no mention that i need a Hwnd to process the class when I first did the CAsynSocket::Socket call with the event notification that I wanted to be informed on
I did notice that
had a valid window
When I first started using CAsyncSocket I know very little about TCPI/IP or OO
at this point looking at Winscok API it has much more flexability so much so it seem I dont necessary need a valid Hwnd but a kernel object such as that from CreateEvent will do
more so It seems if I want to pass notification to a different windows I just do another call to
It's probably not fair to send you down a different path, but many years ago I had similar problems and, having some spare time, I decided to make my own set of wrappers for Windows Sockets API. Over time it has grown into a quite capable set of objects that allow you to work with sockets just like you work with C++ streams.
He has a detach on the server side more so before any conversation gets going
My scenario involves the main windows looks if anyone wants to start a conversation with the server if I see it happens a conversation with the server is initiated I want to pass off that socket to a mode less dialog
You don't specify what kind of number it is (floating point, integer), nor how it is provided.
Is the number coming in as a string, for example from argv passed to main? Is the number passed in to a function as a parameter? Does the function need a particular name? Is the number allowed to be negative? Is there a maximum value for the number? Will there be decimal points? Is the number base 10, or base 2, or base 16, or is there a prefix at the front that specifies the radix?
What should the result be if no number is given, or an invalid number is given?
Are there any unit test cases that would provide a good example of how this is supposed to work?
I have an ancient DLL that began life with VC++ 6. It also uses Zlib for compression, again VC++ 6.
Fast forward a boat load of years and I now have a test app in VS2019. Can't load the DLL. Cannot find old debug libraries, etc.
Given that you have a DLL, you don't necessarily have the ability to recompile it. Let's say we cannot for the moment. Am I left installing ancient SDKs so that those DLLs are available for my custom dll? Don't think how to fix this, I'm trying to understand how to manage MS's myriad versions of SDKS all over my laptop. What do you do to limit the insanity?
Next question - best, most sane approach to move forward? Seems to me I need to rebuild the dll, the test app, etc so they all sync up. But I'm concerned about my customer elsewhere in the world. Do they need to install and SDK? I suspect I need to create an MSI that includes specific runtime kits.
Appreciate any guidance.
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Not sure if it will fit your case but here is how I got about a similar problem:
1. make a clean virtual machine (VMware, VirtualBox, whatever you want)
2. install your DLL and use DEPENDS to find what missing SDK libraries you need
3. try to run your test app and fine tune between different versions of SDK until you make it run.
The advantage of working on a VM is that you can go back to known snapshot points and not get the "it runs on my machine" situation.
Going forward, I'd say the best thing would be to rebuild your DLL with as little external dependencies as possible. Link everything, including the runtime libraries, as static libraries. That way you can distribute your DLL without worrying about needed SDKs.
Linking with static libraries will solve the problem only if the only parameters passed between the caller and the DLL are simple objects (char, int, ...), pointers to simple objects, or pointers to arrays of simple objects. If you try to pass something like a FILE*, there is no guarantee that the caller and the DLL agree on the format.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
You could try running the code with modern libraries, and it is possible (although less probable) that it would work. But much safer to rebuild completely, since the dependencies are often hidden deep in the libraries or OS. One thing you may like to consider is whether you really need your library as a DLL rather than static. The only advantage of using a dll is in situations where you have multiple active applications that are all calling in to it. If it is only used by a single application then a static library, or even no library, is a better choice.