The file type can be guessed from the extension, although that does not guarantee the content. It is not possible to guess the encryption type; after all that is part of the reason for encryption, to hide information about the file's contents.
Hi to all, I am writing a program which will copy a directory tree and delete the source, every thing works as planned, but given that a reparse point could point anywhere (even network drives), one need to be careful when deleting recursively, it could end up deleting way more than on a target system.
How to deal with this situation when dealing with FILE_ATTRIBUTE_REPARSE_POINT, whether it is a recursive copy routine or delete routine.
I've read that the position of the word unsigned isn't important, though I'm not sure if this is an addition made over the years, or if it has been a part of c (&c++) since day 0.
sizeof(long) and sizeof(int) are both the same on a 32 bit system - 4. If memory serves me correctly, in the old days of my experience with 16-Bit turbo C++ 3.1, a long was 4 bytes long and an int was 2 bytes. Not sure if the sizeof operator returns the largest of the two or something else. sizeof(long long) for instance, is 8. So, I don't know if long int is a type in and of itself, as long long is, or if its seen as being a long modification of the int data type.
The StackOverflow community generally have someone online with the c/c++ specs seemingly committed to memory.
The optional keywords signed and unsigned can precede or follow any of the integral types, except enum, and can also be used alone as type specifiers, in which case they are understood as signed int and unsigned int, respectively. When used alone, the keyword int is assumed to be signed. When used alone, the keywords long and short are understood as long int and short int.
Hello everybody, I'm new in this forum. I don't know where to place this thread, because it's about VB6 and C, but I think the problem is in the C code so here I am. I'm working with C with no special focus, so the solution can be in C++ too
Well, this is the problem. I have a VB6 program that simply calls a function when the Command1 is pressed. This one:
PublicFunction SampleSub(ByVal x AsInteger, ByVal y AsInteger) AsBoolean
MsgBox "Hello world!"
SampleSub = TrueEndFunction
0x00401B90 is the pointer to the VB6 function. Then I place this DLL into the VB6 program memory space and the function is called. But it simply doesn't work. Debugging this with OllyDbg gives me this error when calling the function:
Access violation when reading 
I'm 100% sure that the function is at the address 0x00401B90. VB6 uses __stdcall and I use __stdcall from C. VB6 uses 16-bit integers and I use 16-bit integers (WORD) from C.
Hello. Thanks for the answer. No, the SampleSub() function is inside a VB6 program, an executable. Then I build a C DLL with the code above and inject it on the VB6 process. Sorry if I don't explain that very well.
I would experiment with calling other VB6 functions to see if they give the same result. Especially try calling a function that takes no parameters to see if the problem might be the parameter passing.
Have you ever had success calling a VB6 function from C?
The difficult we do right away...
...the impossible takes slightly longer.
Hi, thanks for your answer. I tried calling a function without parameters and without return value and it doesn't work. This is the VB function now:
MsgBox "Hello world!"EndSub
And the new C prototype:
typedefvoid (__stdcall *SampleSubPtr)(void);
But the same Access violation error (that says OllyDbg).
In the past I was able to call a VB6 function from C, that's why I'm so angry! But I just can't remeber how I did it. I'm sure I did it like I'm doing now, but I don't know why it doesn't work . Now SampleSub() is at 0x00401BC0.
Do you think that the way of compiling, the language (if C or C++) or something like that is causing errors? Because I'm 90% sure that the code is the same that the one I used in the past to call a VB6 function, so I need to think that I'm compiling wrong or something like that. I'm compiling like this (or that's what CodeBlocks does for me ).
Btw, your original code has several bugs. The Visual Basic 6 Boolean is actually a VARIANT_BOOL[^] from the C++ programmers point of view. This is a difference of sizeof(short) versus sizeof(int). Also... most VB6 data types are actually VARIANTS^