Non lo puoi fare per un semplice motivo. VB non può esporre funzioni pubbliche richiamabili esternamente. Puoi solo esporre funzionalità tramite COM. Nel qual caso chiamarle da VC++ è facile come chiamare un qualunque altro oggetto COM automation.

I masterizzatori non sono mai stati in realtà supportati molto da Windows.
È solo con win2000 che è comparso nell'SDK la sezione: "Removable Storage Manager", e con essa l'API che fa per lei: GetNtmsObjectInformation().
Se non puo limitarsi ad usare win2000 per risolvere i suoi problemi le consiglio di fare un salto su http://sourceforge.net/. Da questo sito ho scaricato tempo fa, per curiosità, il codice sorgente di un software Open Source per masterizzatori. Sono certo che tra le righe di quei sorgenti troverà quanto le serve.
Saluti

In realtà non esistono particolari differenze tra il metodo CreateObject diretto di VBScript (o il suo equivalente JScript) e l'omonimo metodo dell'oggetto Server di ASP. In molti casi, anzi, usare uno o l'altro è assolutamente indifferente. Vi sono solo alcune circostanze da tenere presente e solo un caso in cui Server.CreateObject fa la differenza.
Innanzitutto, il motore di scripting di VBScript è leggermente e mediamente più veloce di quello di JScript, almeno per quanto riguarda la creazione di oggetti. Non si tratta di differenze abissali intendiamoci ma tutto può fare brodo quando si tratta di server.
L'unica cosa che Server.CreateObject fa in più rispetto alla più semplice CreateObject è mettere l'oggetto in condizione di effettuare chiamate agli oggetti nativi ASP quali Response e Request. In altre parole, se dovete creare un'istanza di ADO non vi è differenza alcuna. Se dovete creare un'istanza di un oggetto che internamente usa gli oggetti ASP allora è obbligatorio usare Server.CreateObject.
Un'altra considerazione interessante è che dichiarare un oggetto tramite il tag <OBJECT> offre una performance leggermente migliore non tanto in velocità quanto nell'uso della memoria. Un oggetto dichiarato come <OBJECT> infatti viene istanziato da ASP solo nel momento in cui viene effettivamente utilizzato. Mentre potete mettere in cima alla pagina una serie di tag <OBJECT> senza problemi, sappiate che una analoga serie di chiamate a Server.CreateObject oppure CreateObject creerebbe una lunga serie di oggetti COM attivi con conseguente occupazione non ottimale di memoria.

Probabilmente MSDN non parla dell'API per salvare risorse modificate per il semplice motivo che l'API in questione non c'è.Naturalmente la cosa si può fare. Il prezzo è studiarsi il formato PE degli eseguibili, e il formato delle risorse. Può anche prendersi i sorgenti del compilatore Open Source MinGW, visto che in mezzo c'è anche un compilatore di risorse. Si può fare, ma sospetto con molto lavoro faticoso insomma.
Saluti

Non uso le MFC da tanto tempo perché sono dell'opinione che il modo più veloce di risolvere i problemi è non averli affatto. Nel suo caso tra MFC, OLE e il più che famigerato controllo rich edit che ci sta sotto, mi meraviglio che non si sia formattato il suo PC.
Anche se risolve in modo ortodosso il suo problema, le rimarrà sempre quello delle versioni di questo controllo. Tenga conto che conosco più di una persona che si installa su win2000 la DLL di sistema con il rich edit di win98 perché la vecchia versione funziona meglio.
Le consiglio di aggirare il problema creando un nuovo controllo static, o una nuova finestra, mettendolo sopra il controllo rich edit, e disegnandoci dentro la sua figura. Dentro il controllo rich edit può metterci un semplice rettangolo nero, appunto come segna posto. Il codice in C/C++.
Prima però di valutare questa strada drastico, vorrei consigliarle di dare un'occhiata agli esempi dell'SDK in C. Spesso la qualità del codice è molto meglio di quella che può trovare sul MSDN.
Saluti