typeid depends on RTTI being turned on. RTTI is part of the language standard but C++ turns it off by default. Change your project settings to enable RTTI and you will get rid of the compile-time warning and the run-time exception.

You may have corrupted the heap. Usually this is because you've written to an uninitialized pointer, or written before/beyong the end of an array or object that you've previously allocated on the heap.

In other words, you can't meaningfully serialize a HANDLE, because when you read it back in (presumably in a different process) that HANDLE value won't be meaningful.

Need to pass input into your function by reference: void erase_if (Input& input, Predicate p) But the compiler might have trouble matching that function signature to a template function (I don't know exactly what the rules are). Perhaps if you wrote the function assuming Input was a pointer type, so you would use input->erase (remove_if (input->begin (), input->end (), p), input->end ()); That way the compiler would be forced to treat it as passed by reference, and you'd be forced to code it that way.

To get them to talk you have to change the firewall on the server side to forward a port to the server machine-- how you do this depends on your firewall.

The restrictions aren't put in when the VM is started, but sometime later with a call to System.setSecurityManager

If code you don't control is putting the Java code in a restricted sandbox, there isn't a lot you can do (that's what the sandbox features is for, after all). Do you know the details of the sandbox restrictions? Do you get a SecurityException when you try to connect to a local socket from the Java?

You don't need to provide one for CByteArray if you provide one for DATAGRAM (that does not rely on CByteArray having a copy constructor)

I'm going to pretend to be an expert on this because I just hooked up a browser-based Java application to a complex C++ library using JNI. To get meaningful communication between the Java applet and your C++ application, you are probably going to need to remove the security restrictions on the applet so it runs outside the browser's sandbox. You can do this by signing the applet with a cryptographic signature, or by running the Java code as an application instead of an applet. Once you do this, the Java app and your C++ app can communicate by sockets, or writing files to the local filesystem, or you could use JNI (or COM if the applet is written for the Microsoft VM) and package your C++ app as a DLL that the Java applet can call. If you can't or don't want to change the security restrictions on the Java applet, pretty much the only way to get it to communicate is to have both it and your C++ app talk to the same server on the applet's host (I suppose you could also send Windows messages to the applet's window, but that's a really limited form of communication). Applets are allowed to open a socket, but only back to a server on the host from which they were downloaded. Hosting the applet on your local machine might work for you as well.

You can't initialize a static const in the class definition (confuses the compiler). Declare the variable in the class definition, then in the .cpp file put const int CoClass::MAX_SPEED = 500;

Almost certainly you are overwriting the stack somewhere before you call ProcessShellCommand. If you can't find the mistake by inspection (get someone else's eyes on it) and you don't want to invest in something like BoundsChecker or Purify, you might try a technique I've used in similar situations: Comment out suspect code until the crash goes away, then uncomment some until the crash comes back, and use a binary search to narrow down onto your mistake.

Yes-- Just define the specialization of the function in the header file after the template definition. Like this: template <typename foo> class bar { public : int func1() { ... } int func2() { ... } ... } // Specialization of func2 in bar for class q template<> bar<q>::func2() { ... }

The potential problem I see is in interpreting the LPVOID DeviceString as a ByRef String. If I remember my VB right, a ByRef String is passed to a C function as a pointer to BSTR. That may not be (probably is not) what the C function is expecting. An LPVOID doesn't give very much information about what it is expecting: it could be a null-terminated string, a null-terminated wide-string, a BSTR or perhaps a pointer to BSTR. Do you have source for that C function, or a C example of its use?

sizeof( ) is your friend here. Remember, it will give you the size of the whole array, so you have to divide by the size of each element.

It's very common for reads from the video buffer to be slow. The details of why depends on your specific hardware and directx driver. In general terms the video buffer is not just another block of RAM; after you are done writing to it, it may not contain exactly what you put in yet (or ever). DirectX tries to hide these details, but when you read from video memory it has to make everything synch up so it behaves like you expected it to. The most common workaround is to rework your application so it does not have to read from the video buffer. It's seldom absolutely necessary.

You have to understand that an LPSTR is a very primitive thing: a pointer to an array of characters that is supposed to have a \0 on the end. You can do operations with LPSTR (look at the strcat function) but you have to make sure that you have allocated another array to hold the result that is large enough. Manipulating strings this way has been done for years in C and has led to innumerable buffer overflow errors. You should never do it in C++. You should use the string classes (std::string, std::wstring for wide characters) that are in the standard library, which take care of buffer allocation (and many other useful things) for you. You can concatenate std::string with the overloaded + operator and get just what you expect.

It's not that different from creating a COM interface for you application (in fact, that's one path you can take: create a COM interface and use a COM/CORBA gateway app). You design an interface for the application (that is, the services it will provide to other applications) in IDL. You then run the IDL through the IDL compiler provided by your Object Request Broker (for a COM object you run the IDL through MIDL). The IDL compiler will generate code that has the C++ interfaces to the functions you described in IDL. You write the implementation of those functions, using the rest of your application. Then you link that together with your application and libraries provided by the ORB vendor. Usually, if you are being asked to do this your employer will have an ORB in mind. You'll have to get details from the ORB documentation. I think there are at least one or two open source ORBs around, as well.

stds::sort is a template function. That means the arguments for the function determines what kind of code the compiler generates for the function (as opposed to a regular function, where the compiler always generates the same code). A template argument must be either a type or a constant--the compiler must be able to determine what the argument is at compile time, so it knows what code to generate. For the sort function, the template argument might have been a functor type or it might have been a constant that resolves to a function pointer. If you think about it, you can see how making the argument a type gives much more flexibility to the user of the template function, so that is the choice that the template designer made.

This type of application is very typical of what people have been using Java to do. IBM's whole Linux push is based on Java applications.

A project like that that needs to be cross-platform really should be written in Java. Run the same code on Windows, Linux and most other Unixes. Easier to code than C++ (especially since all the platform-compatibility issues are taken care of), rich, mature libraries and plenty of 3rd-party free and commercial stuff you can build from.