|
|
Thanks talk about fair I don’t think it’s fair for Microsoft to Have us use CAsyncSocket
Just my opinion
|
|
|
|
|
|
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
Thanks
|
|
|
|
|
Count the digits of a given number c programming
|
|
|
|
|
Ok. Did that. Did you?
Keep Calm and Carry On
|
|
|
|
|
That's not how it works around here. We're not here to do your work for you.
We'll help you with your code if you got specific questions or problems, but that's it.
|
|
|
|
|
Quote: Count the digits of a given number c programming
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?
|
|
|
|
|
SARKER MD KAWSER ALOM wrote: Count the digits of a given number c programming
First try to count the digits of a given number without c programming. Only with a peace of paper and a pencil!
|
|
|
|
|
#include <stdio.h>
#include <math.h>
int main() {
int number = 1234567;
int digits = log10(number)+1;
printf("%d has %d digits\n",number,digits);
}
Try it here[^]
|
|
|
|
|
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.
Charlie Gilley
<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.
Mircea
|
|
|
|
|
This is good advice, with one caveat.
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.
|
|
|
|
|
Truth there. The good news is that I know who my customers are and all of the data types are simple.
Shudder, I cannot imagine passing a file pointer but I guess someone might do it 
Charlie Gilley
<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
|
|
|
|
|
I admit I'm rusty here and rebuilding my knowledge base on how all of this works. I do have a clean Xp machines, excellent suggestion.
Charlie Gilley
<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
|
|
|
|
|
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.
|
|
|
|
|
Quote: The only advantage of using a dll is in situations where you have multiple active applications that are all calling in to it.
There are some other cases. Once I had a data collection app that needed to interface with potentially hundreds of different instruments. Having a monolithic app would have been impractical.
Mircea
|
|
|
|
|
Well once it is in memory and the dll is loaded it will take up pretty much the same space as it would with a static library.
|
|
|
|
|
The thing was, in my case, that no user had all the instruments. Forcing them to load all the unused code would have been too taxing.
Pretty much the same case as an OS that needs drivers (DLLs) for different devices. Loading code for all wouldn’t be a solution.
Mircea
|
|
|
|
|
This is where I am struggling. Not using a DLL just won't work for this application as it allows independent applications to talk to our system.
The issue at hand (I think) is that I have Visual Studio / Microsoft rot. My laptop is over 4 years old, and I just don't pay attention to the ramifications of installing <insert version="" here=""> of visual studio that may in fact also install an SDK. The development environment is a hodge podge mix of this stuff. It's almost certainly why everything is confused at the moment. I'm trying to clean it up.
So, it's my understanding that all of these OS dlls come from the SDKs, am I correct? These SDKs tend to be generally related to OS releases. If I have a DLL, what's the best practice - make sure I always use the latest SDK? This also trails into the runtime libraries that are a necessary part of an installation package. Off to msdn...
Charlie Gilley
<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
|
|
|
|
|
charlieg wrote: The issue at hand ...
 . That certainly needs to be fixed.
charlieg wrote: So, it's my understanding that all of these OS dlls ...
Windows itself contains all the standard run time libraries. If you want to develop your own applications then you need a compiler and its associated SDKs (.lib and .dll files), some of which may be newer versions than the Windows versions. Once you build your application then you need to ensure that the correct .dlls are installed on any system that installs the application. That is why you need installers, rather than just copying the .exe files.
Visual Studio has all the tools necessary to do this, although most people seem to prefer one of the non-Microsoft installers.
|
|
|
|
|
My understanding as well. I have some clean Windows 10 Professional VMs, so I'll start with those.
Charlie Gilley
<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
|
|
|
|
|
oh the life of manufacturing systems.
If I build a dll on a Windows 10 machine, is there hope for it to run under Xp? Assuming I don't do anything silly and use post Windows Xp features?
I've just discovered with this inherited piece of code that the customer runs it under Xp. I'm thinking just use the Xp tools and stay there.
Charlie Gilley
<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
|
|
|
|
|
Judging by other reports I have seen the answer is: it depends. Microsoft has never tried to be backwards compatible in their systems but some applications will still work. The only way to find out would be exhaustive testing. But for a commercial product I would suggest that you should stick to XP for all development and testing.
|
|
|
|
|
By any slim chance, does anyone have the code for triangular plate bending finite elements? I'm looking first for the stiffness matrix. I can read C, Fortran, python, Java and probably figure out some others. Any help would be appreciated - Thanks, Ed
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
