CPallini wrote:

You can ignored most of this difference, because Visual Basic will automatically convert any Unicode BSTRs to ASCII before passing them to an external function.

This will mean that VB pass strings to DLLs as ANSI, but what's about the opposite: what VB does with strings returned by a DLL function call?

As far as I know, the VB6 strings are unicode and their VC correspondant is the BSTR type...

Very good explaination! Deserves a 5!

That will work, but is not the right way: as the MyDll::MyOwnDll.PrintMsg() method is static, you don't need to instantiate an object of your class to call it. The right way is the following:

void MyProjDlg::MyMsg()
{
MyDll::MyOwnDll::PrintMsg();
}

On your header file you have declared your export as __declspec(dllexport): this is right as it instruct the compiler that the method MyOwnDll::PrintMsg() is implemented in your code and should be exported from the library. On the other hand, when you use the dll, you should include the header file, but you need the MyOwnDll::PrintMsg() method to be imported, then it should be declared as __declspec(dllimport). A typical approach, is to add a pre-processor definition in your dll project, for example MYOWNDLLPRJ, and modify the header file as follow:

#ifdef MYOWNDLLPRJ
#define MYOWNDLLAPI __declspec(dllexport)
#else
#define MYOWNDLLAPI __declspec(dllimport)
#endif

namespace MyDll
{
class MyOwnDll
{
//function here
static MYOWNDLLAPI void PrintMsg();
};
}

yu-jian wrote:

In the kernel Mode, all the program can run, it runs on the ring0 and can visit all the I/O port.

What does all the program can run mean? In kernel mode your code runs at ring 0, so you can use privileged instructions of the processor, but you have too much constraints. For example you can call only a subset of the system API depending on the IRQL your driver is running on.

yu-jian wrote:

In the user Mode. only a part of program can be run. It runs on the ring3. Some operations of the program will be fobidden.

What does this sentence means? At ring 3 you cannot use privileged instructions of the processor: if you try to use them an exception is thrown. Said that there are no limits on which parts of your code could be executed or not.

As Superman already wrote, declaring an array with zero size is not allowed, at least on Microsoft Visual C++. Something interesting is that, on versions prior to Visual Studio 2010, which is the first one that implements static_assert, such functionality was realized using the _STATIC_ASSERT Macro[^]. That macro tests at compile time for the given condition and give the Compiler Error C2466[^] if not satisfied. Ops! C2466 means cannot allocate an array of constant size 0. By going deeper, we can search the macro on the crtdbg.h header:

#define _STATIC_ASSERT(expr) typedef char __static_assert_t[ (expr) ]

Now, let's try to imagine how it works...

Let's rewrite your equation as y2 = z - 3x2. Then y = sqrt(z - 3x2). We can easily see that there are no solutions for z < 3. Now we can write the following code (is C code, but it's easy to port it to another language):

int f(int z)
{
int result = 0;
int x = 0;
double m = 0; // m is 3*x*x
double y;

if (z < 3) return 0; // You could remove this line (the function will continue to work properly)

while (m <= z)
{
y = sqrt(z - m);

  // Test if y is integer...
  if (y == floor(y)) result++;

  x++;
  m = 3\*x\*x;

}

return result;
}

Note that this function has a complexity of O(z-2) as it checks for all possible integers values of x. Also note that this implementation accept solutions where x and/or y are zero (e.g. f(4) returns 2 and the solutions found are { 0, 2 } and { 1 ,1 }). If you want solutions with x and y stricly positive you should initialize the loop with x = 1 and m = 3, and inside the loop ignore solutions with y == 0.

The function and method names are decorated accordingly to the used calling convention, anyway what you can extract from a decorated name is, at most, the type of the formal parameters of a function (e.g. int, char *, struct MyStruct &, etc.), but not the name used in the source code.

Please, don't cross post. You have already posted the same question on Q&A (and you got an answer there).

Wow! Fantastic article: even those who already know the topic should read (and learn) it!

In your example you are returning a basic datatype (an integer), then it's quite the same to return by reference or by value: for example on a 32 bit environment, returning by reference means load the address of m_myVar inside the eax register, while returning by value means load the content of m_myVar inside that register. The inlined versions of your methods could potentially be better, because the compiler could better optimize the usage of CPU registers and produce a code a bit more efficient. If your methods return a class or a struct the things could be different: returning by value means that your methods should allocate a temporary object on the stack and call its copy constructor. Then returning by reference in most of cases is better.

The key you pointed out holds informations about the CD/DVD drive... What the enquirer seems to ask for is something like an identifier of the disc

Member 2883067 wrote:

From Ole Server Application do we have to call this (WM_QUERYENDSESSION)

What you precisely mean with this sentence? The WM_QUERYENDSESSION message is sent by Windows in the initial steps of a shutdown. If you want to shutdown the operating system (turn-off, reboot, ...) you should use the ExitWindowsEx Function (Windows)[^], that logs off the interactive user, shuts down the system, or shuts down and restarts the system. It sends the WM_QUERYENDSESSION message to all applications to determine if they can be terminated. For an example on how to use that API, see How to Shut Down the System (Windows)[^]

The problem is that you are returning a pointer to a buffer that will go out of scope after your function exit: then then returned pointer is no longer valid and what you find there is going to be pseudo-random. To fix the problem you can:

1. allocate the output buffer out from the function
2. allocate the output buffer using new or malloc (but you should remember to deallocate it when it is no more needed)

However, as Alan said, the very best way is to stop using C-style strings and use std::string instead: the STL is one of the better solutions because all its classes are inlined and highly optimized. This will give you very good performances with a minimal footprint (the unused classes and methods simply are not compiled and don't affect the executable size).

You have misunderstood the code:

• The UuDecodeLength and UuEncodeLength functions get the length of a string as parameter and return the required length of the correspondant decoded/encoded string.
• The UuDecode and UuEncode functions get three parameters: an output buffer, an input string and the length of the input string. They return the number of bytes written to the output buffer, and put on the output buffer the decoded/encoded version of the input string.

I tried this on my PC:

int main(int argc, char* argv[])
{
INT8U in = "12";
INT8U* out = (INT8U*)malloc(UuEncodeLength(2));
INT32U n = UuEncode(out, in, 2);

// Put a breakpoint here and look what happened
// Now n is 3 and inside out you find ",3(" i.e.:
// out[0] = ','
// out[1] = '3'
// out[2] = '('

free(out);
}

djfresh wrote:

The method "UuEncodeLength" returns me the same length...

This is not true; look at its code:

INT32U UuEncodeLength(INT32U nSrcLen)
{
INT32U uDestLen;
uDestLen = (nSrcLen * 4) / 3;
if ( ((nSrcLen * 4) % 3) != 0 )
{ // we need a partial byte, add one...
uDestLen++;
}
return uDestLen;
}

Now let's look at what happen:

• if nSrcLen = 1 then the function returns 2;
• if nSrcLen = 2 then the function returns 3;
• if nSrcLen = 3 then the function returns 4;
• if nSrcLen = 4 then the function returns 6;
• and so on...

No! No one will do your job for you! Please make an effort and came back with questions about specific issues, showing what have you already done, explaining why it doesn't work as you expected and possibly adding a code snippet of the relevant code!

I'm not sure that it is the solution, but you can try to add the DS_CONTROL style to your window (see What is the DS_CONTROL style for?[^] for more informations). You can do it from the Resource Editor: open your dialog and on its properties, set Control to TRUE.

Don't worry! My goal was not to blame you, but only to make you aware about cross-posting! :thumbsup: