Im dont fancy myself a C++ programmer anymore, but i *can* if i have to. After much frustration with AutoCad's SDK and VC++ i managed to compile would be .dll's for AutoCad addins, but renamed as "arx" since AutoCad like it fancy.

My problem is the SDK has *Alot* of C++ Classes and Objects. This basically means im foooooked if i wanted to write my own dll's and rename them as ARX's from Masm (at least i think so ~ I have all the lib's and headers, but there still are C++ classes in the headers, not simple API. This is why i think it cant be done (am i wrong here??) ).

Since I prefer MASM for my adventures, i would like to find a way of merging both worlds. The idea im kicking around, is to build a basic empty shell in C++ that will handle all the AutoCad objects i need to deal with, but for all other stuff (windows, menus, etc) i would call precompiled masm functions. Whats your thoughts here.. Is this easily achieved from VC++?

The alternate is to use this SKD, and all its libs/headers, and write API like wrappers around all the Class stuff, and make a lib outa the OBJ's. Then i would write exclusively in MASM and link the wrapper lib, as well as the sdk libs. (This would require alot more setup overhead, but its worth it to me if it will work). Again whats your thoughts?

Im by not a VC++ pro by any extent, and never tried anything close to this, so im looking for your help and thoughts here for a good course of action.

Thanx alot!
Posted on 2003-04-14 21:33:53 by NaN
easiest way of handling it will probably be to write the stuff in C++, classes and all, and call external asm functions from your class methods. At least that's guaranteed to work, and won't be compiler specific. Why you want to write it in full asm is beyond me, but if that floats your boat :rolleyes:

If autocad had used the COM model, it should be trivial to write it in full asm. Or... rather, the COM objects are easy to implement in asm, while the model has a lot of cheeky stuff.
Posted on 2003-04-15 02:19:20 by f0dder
Why you want to write it in full asm is beyond me, but if that floats your boat
hey, you should definitely float that boat! :)

I think, it depends on the used C++ stuff. It's not so difficult to communicate with simple C++ data types, like CString or CWindow. You could try to watch some C++ disassembly, so you can look up, how to do. If you need more stuff from C++, the way, you/f0dder described is propably the best.
Posted on 2003-04-15 02:42:52 by beaster
Communicating in one thing, but creating new class instances is another.

This is not COM C++ programming. They have their own API structure in place for this sorta thing, and expect Class instances to be generated for certain called to their API's.

Here is an example source:

AcGePoint3d startPt(4.0, 2.0, 0.0);
AcGePoint3d endPt(10.0, 7.0, 0.0);
AcDbLine *pLine = new AcDbLine(startPt, endPt);

AcDbBlockTable *pBlockTable;
->getSymbolTable(pBlockTable, AcDb::kForRead);

AcDbBlockTableRecord *pBlockTableRecord;
pBlockTable->getAt(ACDB_MODEL_SPACE, pBlockTableRecord,

AcDbObjectId lineId;
pBlockTableRecord->appendAcDbEntity(lineId, pLine);


return lineId;

There is alot of objects here to use (AcDbBlockTable, AcDbBlockTableRecord), and create instances of (AcDbLine)

I already have the COM automation mastered for AutoCad with MASM. But im now venturing into this corner of the world. Its alot faster than com, because it directly loads into the AutoCad's process. I just dont like C++ 's address of "&" and pointers "*" stuff that gets things all confusing. Which is why i would like to have a MASM equivalent for this stuff. All the fluf turns straight forward at the MASM level, and i dont have to get into a bitch fight with the compiler being picky over how the fluf is declaired :rolleyes: )

Posted on 2003-04-15 15:52:42 by NaN