None, aside from the naming convention.

Essential COM (Don Box) - it goes into a lot of depth and can be quite daunting in places but it's a goldmine of important information.

MSDN (Microsoft's Developer web pages) will tell you everything you need to know. Also, you might want to try Google, using "BSTR" and/or "VARIANT" as your search parameters. msdn.microsoft.com www.google.com :) Hope that helps!

Assuming you're using the MS compiler, why not just view the CRT library source?

MFC is very particular about outstanding COM references when it shuts down. If you're using a STA, you may want to call AfxOleInit() in your CxxxApp::InitInstance() and let MFC take care of uninitialisation rather than explicitly calling CoInitialize(NULL) and CoUninitialize() in your code. Obviously, if things are a little more complicated or you want to support multiple STAs or a MTA, AfxOleInit() will not suffice. Hope that helps.

er, maybe this is a trick question, but how about: _bstr_t t(L"test"); wchar_t* p = t;

Yep, that's perfectly valid (and arguably the "right" way) but then you have an extra step of publishing the interface and managing proxy stubs. My way keeps things simple and flexible.

Yes, use sizeof(YourStruct). If you have embedded structs, you're going to have to be more creative e.g. sizeof(YourStruct) + (sizeof(YourEmbeddedStruct) * NumberOfEmbeddedStructs) etc. It can get tricky if your structs contain "variable" data, such as strings. In the past, I've either defined the maximum size of the string (and therefore constrained the array inside the struct definition) or I've added a counter then a pointer, e.g. ... unsigned long ByteCount; unsigned char* pByteData; }; The count tells the caller how big the variable data is. Hope that helps.

If you've written both client and server (and so can control alignment and other compile-time issues), you could create a common header file for both applications that contains the struct definition and then embed the data as a byte stream (VT_UI1|VT_ARRAY) in a VARIANT and pass that over (D)COM. I've used that method successfully in the past and its reasonably flexible.

In the resource editor, open the properties for your dialog and select the Border style to be "Resizing". You will then need to handle the WM_SIZE message in your dialog's code (use ClassWizard) so that you can handle the resizing/repositioning of any child controls when the dialog is resized. This is a pretty common problem when using dialogs under MFC and there are a boatload of solutions, many of them on here. I recommend searching for Paolo Messina's dialog resizing solution which works nicely. Hope that helps...

You might want to look at CreateDIBSection. This is similar to what you already have (it will return a HBITMAP handle and a pointer to the bits). You can directly modify the bits via that pointer and use the handle for selecting the object into DCs. If you simply want to create a 24-bit colour image, you don't need to create palette information in the BITMAPINFOHEADER (set those values to 0). Then simply write an RGB TRIPLE (Blue, Green, Red) for each pixel using the pointer. Remember you will need to pad each scanline to the DWORD boundary. If you want to write a 256-colour (paletted) image, you will need to provide a colour table. Check out MSDN documentation for that information. Another gotcha is that if you want the bitmap to be "top-down" i.e. pixel (0,0) is in the top-left corner, you must specify a NEGATIVE height value in the BITMAPINFOHEADER structure. Hope that helps

Although the former is valid C++ syntax, I think the VC6 compiler will have issues with it.

You need to provide an entry point for the executable. Goto Project settings, Linker, Output and type wWinMainCRTStartup into the "Entry-point symbol" field.

use FTP? The WinInet library (wininet.lib) has a comprehensive set of functions to do just that (see MSDN). You will have to run a FTP server on your server box though - you can either use IIS or a dedicated application such as Bulletproof FTP.

Why not use: TCHAR szDrive[_MAX_DRIVE]; TCHAR szDir[_MAX_DIR]; TCHAR szFname[_MAX_FNAME]; TCHAR szExt[_MAX_EXT]; ::_tsplitpath(csPath, szDrive, szDir, szFname, szExt); Then, just check to see if you have the filename and extension in szFname and szExt.

Just make sure you call CoInitialize[Ex] to create a COM apartment and CoUnInitialize to destroy it (before exiting your app). It can do no harm to include comdef.h if you want to use some of the COM helper classes such as _variant_t. Also, you might want to set the _WIN32_DCOM preprocessor directive which will include all the relevant COM headers. Hope that helps...

Your test variable is a pointer to a SINGLE char value. If you want to store an array of chars i.e. a string, you will have to declare an array: char* pArray = new char[NumChars + 1]; where NumChars is the number of characters you want to store. If you don't know in advance how many you want to store, pick a large constant value. Note the extra one added to accommodate the null-terminator at the end of the string. This is a style issue, you may wish to include the null-terminator in the NumChars count. Now when you use your pointer arithmetic: StringData++; you will be using valid allocated memory. Remember that when you come to deallocate an array, the syntax is as follows: delete []pArray; // Note the square brackets On a related note, you might want to look at the standard library's basic_string<> template (STL). use MSDN - it can simpify string handling a great deal and is a good way to learn about templates. Hope that helps.

I presume you are passing a custom message to your window, e.g. WM_MYMESSAGE or something (defined from WM_USER + or you've used RegisterMessage)? I'm also assuming that your message handler is something like: LRESULT OnMyMessage(WPARAM wParam, LPARAM lParam); You MUST make sure that you include the WPARAM and LPARAM arguments. Omitting them will work in DEBUG but will NOT work in release build. This is due to the way the stack is padded in debug builds. In a release build, the message map will expect the arguments - if they're not there, you will corrupt the stack, resulting in an exception. Apologies if this is not what you're after, I'm just making blind assumptions from your original post.

You're on the right lines with _inp() and _outp() but if you are using an "NT-based" OS (Win NT, 2000 or XP) you have to use a special driver to bypass the port security - by default you cannot directly access I/O ports. There are a number of drivers available that do the same thing. UserPort is as good as any: http://www.embeddedtronics.com/public/Electronics/minidaq/userport/UserPort.zip Hope that helps

MS Office actually comes with VB help in the form of .chm files although they are pretty well hidden. The path varies slightly from version to version but if you look around: C:\Program Files\Microsoft Office\Office10\1033 (the 1033 is the important bit), you should see a bunch of .chm files. These will give you information on the various methods. It's not perfect, but it does help. There is quite a bit of KB documentation on MSDN, lookup "Office Automation".