|
Stephen Hewitt wrote: I'm no .NET fan but there are lots of things you say which simply aren't true:
Phil C wrote:
a "interpreted intermediate language".
MSIL is not interpreted; it is compiled. There are two main differences between typical compiled languages and .NET:
Hmm, well you are exactly correct. You have a much MUCH better command of the various details of it all than I do including the proper terms and how it's separated out.
However, I do know this for a dead on fact. I've now ported many of my old C++ workhorse functions over to .NET and the result is a program that runs many times slower (for whatever reason).
And yes, you can do pointers, you're right again. I've been forced to do all that many times now, but it's a huge pain and becomes even worse if you are trying to work with third party libraries some in managed and some with unsafe form because you have to carve out sections that are "unsafe". The pinning of object also does work and add to that the Marshal class to get access to managed memory objects...they did give us that.
But all of it still adds up to training wheels to the Ferarri in my opinion.
You see, my area is dealing with and managing various image data. Doing automated inspection, manipulating images from cameras, framegrabbers and looking for defects or whatnot. My programs spend a lot of time doing millions of calculations on big chunks of data. I've been recently forced to use .NET because my hardware has shipped with .NET libraries and I've come face to face with a lot of hard realities of how well/poorly the whole .NET scheme works under my conditions. The old "unsafe" C++ unleashed the true horsepower of the CPU to zip around huge amounts of data, deal with pixels on a byte by byte basis, convert from 8 to 10 to 16 to 24 bits/pixel with ease by using several differnt types of pointers into the same memory area, etc. etc. etc.
I could spend the rest of the day showing examples of hundreds and hundreds of lines of patches I've had to make to what once upon a time was nice clean code.
In conclusion I'll quote Jesse Liberty in the O'Reilly book - Programming C#:
While it is possible to program in .NET with C++, it isn't easy or natural. Frankly, having worked for ten years as a C++ programmer and written a dozen books on the subject, I'd rather have my teeth drilled than work with managed C++.
I couldn't agree with him more.
|
|
|
|
|
Phil C wrote: However, I do know this for a dead on fact. I've now ported many of my old C++ workhorse functions over to .NET and the result is a program that runs many times slower (for whatever reason).
I haven't used .NET much at all but I'm not surprised by its slowness. When one hears how it works it almost impossible to believe it could compare to C++ in speed or memory consumption. I'm no .NET fan.
Steve
|
|
|
|
|
Stephen Hewitt wrote: When one hears how it works it almost impossible to believe it could compare to C++ in speed or memory consumption
I can appreciate the candor 
I admit, I get crusty at times. It's just that all too often people seem to feel that just because something is new (.NET, managed memory, etc.) it's automatically better.
I'm not trying to say .NET and the managed memory model don't have a place and aren't wonderful for some applications. But in my world, which is generally standalone desktop programs that have no interaction with the internet, ASP, web pages, distributed SQL servers etc. etc. the extra layers of "stuff" do nothing but make things 10 times harder, slower and more complex.
If things keep going the way they are I'll probably become one of those (gag) Linux gcc geeks. LOL.
And I'll also be the first to admit that I don't always re-quote all the lingo, correctly. Anymore, the basic concepts of programming are all one big long techno-geek sentence that makes little sense to me. Sad when I think I really did have a pretty good grasp of all the compiling, linking, DLL's, libraries, includes, preprocessor directives, classes, pointers, heaps, stacks...and now I'm a idjut 
|
|
|
|
|
I have a function that is returning an integer, with a few strings being passed by reference. After running the debugger, it seems to run till I call the actual function that resides in a different dll. At that point I receive a window stating:
Unhandled exception at 0x0a30f6da in PCTest.exe: 0xC0000005: Access violation reading location 0xcccccccc.
The value of the external function in the debugger is 0x0a34310c and not 0xcccccccc.
I've set the permissions in the security to allow everyone, all access, (even the directory) but still access violation.
Here's my code, it seems simple enough, but I can not see it...
#include <stdlib.h>
#include <windows.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>
int main()
{
typedef int(* PExportedFn)(char*,char*,char*);
HMODULE hmod;
PExportedFn ExFunc;
char char1ref[10],char2rev[10],char3ref[10];
int ReturnValue;
hmod = LoadLibrary("C:\\MYDIR\\EXTDLL.DLL");
if (hmod != NULL)
{
printf("Succeeded loading library");
ExFunc = (PExportedFn)GetProcAddress(hmod,"FUNC");
if ( ExFunc != NULL)
{
printf("Succeeded loading library");
wcscpy(char1ref, "1234");
ReturnValue = ExFunc(char1ref,char2ref,char3ref);
printf("Succeeded, return value is:%f",ReturnVal);
}
}
else
{
printf("Did Not succeeded loading library");
}
return 0;
}
Any help would be greatly appreciated.
Carl
Lucky_Carl
|
|
|
|
|
|
A callstack would be nice.
Steve
|
|
|
|
|
Hi LuckyCarl,
I have tested your code and it really not give the address of the function.
and got the solution for this.
As C++ by default mangles the name of the function and then link it as per my knowledge
if you create the function in the DLL using
extern "C", it avoids name mangling and function treated as C type function
so your function declaration should like following.
extern "C" __declspec(dllexport) int foo(char*,char*,char*);
and definition like
extern "C" __declspec(dllexport) int foo(char *f1,char*f2,char*f3)
{
...
}
and trying to debug the code for calling the fucntion from another dll
Knock out 'T' from CAN'T
You 'CAN' if you think you 'CAN'
-- modified at 1:10 Saturday 6th May, 2006
|
|
|
|
|
I have debugged the code by creating sample DLL and an application uses it
now what i have faced that when am trying to debug the function called from another dll.The debugger avoids it and gives the result of the function and continue proceed further.
not fired any error as like you.
Knock out 'T' from CAN'T
You 'CAN' if you think you 'CAN'
-- modified at 1:03 Saturday 6th May, 2006
|
|
|
|
|
Hello,
Is there a way for me to change the timeouts
assoicated with the CSocket class? In paticular I need to modify the
timeout used for Connect(). In my case, it takes about 15 secs for it to timeout now, and i'm working with around 25 sockets, so the time could add up if i'm unable to connect to any of them...
Note: I was using CAsyncSockets before, and all my connects came back with 'wsaewouldblock', which was ok, but the problem I was having is, after closing all the sockets (even one's that were not connected), and when the destructor cleans up, my program was crashing in 'sockcore.cpp' (Assertion failure). I do not see this problem switching to CSocket, thus the reason for the switch.
Thanks
|
|
|
|
|
arunkk1 wrote: I need to modify the
timeout used for Connect()
My socket is a little rusty so I may be wrong. I think timeouts are TCP/IP stack configuration settings. So they effect the entire machine. I don't think there is an API to change them directly. It is possible that there are registry keys and values that are OS dependent that contain the configuration. I also vagely remember the connection Timeout is not a straight time based mechanism but involves retry configuration that might be something like TcpMaxConnectRetransmissions.
Anyway if you do not get more specific answers here there are surly MSDN articles and Knowledge Base stuff on that.
"What classes are you using ? You shouldn't call stuff if you have no idea what it does" Christian Graus in the C# forum
led mike
|
|
|
|
|
Hey folks:
Right now we have an ASCII tab-delimited data file that is used in our applications. We really don't want the user accessing this file as they could really mess up the application by screwing up the data file.
Simply by making the file hidden is security by obfuscation, and we want someway of hiding the data.
Ideally, we wouldn't have to encrypt file, perhaps there's a way of preventing the USER from modifying this file, and only allowing our application to access it... someway of locking the file from the user?
I'm a C++/Win32 API newbie, so please make the answers appropriate for someone of my skill. Hopefully there is some easy way of doing this,
David
|
|
|
|
|
chasetoys wrote: someway of hiding the data
1) Host the data file in some directory where the user wouldn't easily find. For example: C:\WINDOWS\system32\foobar\data\
2) Rather than to store data in files, storing the data in the registry.
3) Use some fake name, for example "foobar.DLL", to name the data files.
4) ......
Maxwell Chen
|
|
|
|
|
Another alternative would by to put the data in the .EXE as a resource.
Steve
|
|
|
|
|
Stephen Hewitt wrote: Another alternative would by to put the data in the .EXE as a resource.
1) If the data is increasing, the EXE increases the size then? (I guess YES.)
2) Personally I think that if the data size is relative too large (for ex: 800 MB), it would be not suitable to merge in EXE.
Maxwell Chen
|
|
|
|
|
I think yes increasing and I suggest use from one algorithm coding
|
|
|
|
|
My point is:
Let's say the EXE is now 800 MB as we use a smart algorithm to manage the resource in EXE.
But launching the program might take maybe 5 seconds because we used to have the anti-virus installed. And there is the On-Access scan.
Maxwell Chen
|
|
|
|
|
but why should exe file 800 MB?
you can break this exe file to a little files ( I suggest dll) I think that its not idea exe 800 MB, right?
|
|
|
|
|
You did not follow our discussion.
Stephen suggested to put the original poster's data in the resource portion inside the EXE.
Let's say,
the real executable code of the EXE is just 2M in size (which should be average);
user keeps adding data (thus into the EXE) (for example: all those TEL numbers from a phone book). It results in a 800 MB sized EXE file. 
Maxwell Chen
|
|
|
|
|
yes I see suggestion Stephen and I agree with you that we have increasing
oh yes you said if we enter data to resource we have a big file
|
|
|
|
|
Stephen Hewitt wrote: Another alternative would by to put the data in the .EXE as a resource.
Another issue is: We have to export the data (separate the data from EXE) before we upgrade / replace the EXE.
Maxwell Chen
|
|
|
|
|
chasetoys wrote: someway of locking the file from the user?
Sure there are potentially many ways to do that. While I would not advocate using any of them I can discuss it.
One technique would be to use a Database type design for your application. You would build a Windows Service to do all the file IO and use IPC to communicate between the application and the Service. This way the Service is always running and has the file opened without sharing so no other process can access it. Of course the user can always stop the service and then access the file.
The user does control the computer and if they know how the can access the file regardless of what you might do. About all you can do is make it harder for them. Of course doing that makes it harder to develop the application since more work must go into it. More analysis, design, testing, maintenance, support etc.
You might want to reconsider and stick with hidden folder and file attributes.
"What classes are you using ? You shouldn't call stuff if you have no idea what it does" Christian Graus in the C# forum
led mike
|
|
|
|
|
After reading all this, I think you should:
A) Just make the File Read-Only after your program closes it. This will keep a casual user from accidently damaging editing it. If they actually reset the read-only flag and then edit it, then they are determined and sophisticated enough that they can damage anything if they want to.
B) Make a backup copy of the file when you close your program. Put it in the Windows/System folder or somewhere similar. Yes, this will take up an additional 800 MB of extra data, but if you're worried about data integrity and safety there really is no substitute for making a backup and HD space is cheap. When your program starts back up, check the data file against the copy, if you see any differences then you know someones been messing with it and can take action.
I never cared much for trying to use Hidden files. I tried it a couple times in the past, and inevitably got a tech support call later and when I needed them to go look for, find and tell me something about that hidden file I had a heck of a time explaining to them how to "unhide" that file. (imagine a 5 second question over the phone "You're out of disk space? What's the size of the MYDATA.DAT file?" becoming a 30 minute long lesson in Windows File attributes and how to change them)
Good luck, don't forget...KISS.
|
|
|
|
|
Great advice Phil thanks! A couple of clairifications:
1) Would you advocate combining methods both A & B?
2) Would you just replace the tampered file with the one you have in the Windows directory?
3) Does Windows allow you to use the WriteFile API to write in the Windows directory? I tried to do that once but couldn't... i.e. where would you put the bacakup file, and are you sure Windows lets you do that?
4) Is there a simple API to encrypt/decrypt an ASCII text file? Or is KISS more important here?
Thanks!
|
|
|
|
|
chasetoys wrote: 1) Would you advocate combining methods both A & B?
It's by design. Feel free to use what you prefer.
chasetoys wrote: 2) Would you just replace the tampered file with the one you have in the Windows directory?
Please elaborate more detail. Not really understand what you mean.
chasetoys wrote: 3) Does Windows allow you to use the WriteFile API to write in the Windows directory? I tried to do that once but couldn't... i.e. where would you put the bacakup file, and are you sure Windows lets you do that?
A) It may be the privilege issue. The program is run as the role of "User" instead of "Administrator".
B) Or maybe you did something wrong. Show us your code snipet about creating / writing files.
chasetoys wrote: 4) Is there a simple API to encrypt/decrypt an ASCII text file?
Yes, there are some algorithms for this job, for example: DES, 3DES, AES, RSA, BlowFish, SawFish, etc. You can find those source code of the algorithms by Googling.
Maxwell Chen
|
|
|
|
|
1)From what you described as your requirements I'd do A and B, yes.
2)That depends on what you anticipate the reason for the tempering. I'd probably start out with a messagebox to the user if you detect something wrong. something like:
The database appears to have been changed or corrupted since the program was last run. Rebuilding Database, MB_OKCANCEL
This way, the user at least has an option and has been warned that he may have completely screwed things up when he fooled around with your file. As I said, if he's sophisticated and determined enough to set the read-only attribute to false, then edit the file and finally to ignore the warning message you gave him, there isn't much you can do to stop him and there may be a legitimate reason for him to do it so you can only do so much.
3) Yeah, you're right, I think there is some permission thing that XP has. OK fine, don't put it in Windows\System, but I think there's another separate "Application Data" folder somewhere that's been designated for this type of use. You should be able to find a place, just putting the copy in a completely different folder goes a long way to making thngs more secure both from a tampering issue and crash-proofing.
4) I think someone else already answered this, yes there are ways. Personally I wouldn't bother. You mentioned that your data file can get fairly large. Whatever you do to encrypt/decrypt it will cause things to slow down, introduce bugs and will probably have a lot of other drawbacks too. ie. what if YOU want to edit the file to check for bugs, problems during development? If the thing is unreadable you are only making things harder on yourself. On the other hand, if you really really don't want anyone to see what's inside (prevent unwanted reverse engineering for example) then maybe it's worth all the extra time and trouble. This one is really something only you can answer.
Good luck 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
