The MASM Forum Archive 2004 to 2012

Hi all,

I've uploaded a minor change to the headers, I have still not integrated the Win7 headers to the main ones as I have less time than I expected to work on them and they are extensive. The upload consists of the minor edits I have made over the last few months. These are generally corrections or type definitions that allow for more seamless switching between Win64 and Win32 versions. Also this thread (http://www.masm32.com/board/index.php?topic=13107.0) by Tapejara demonstrated an error in Windef.h that has been corrected, the TCHAR and TBYTE types were not being changed to WORDs when STRINGS UNICODE was defined or when a Unicode encoded file was assembled. The version has been incremented to GOASMHDRVER = 0x020012, no major additions were made to the project for this release.

Note that if you wish to distribute your source code and are using TCHAR or TBYTE you will want to ensure the proper version of the headers is used with the following conditional compilation:

#IF GOASMHDRVER < 0x020012
GOASM_ECHO This program requires headers version 2.00.12 or greater
GOASM_EXIT
#ENDIF

You are my favourite donkey ! Thanks for your work !   :cheekygreen:

I have uploaded an interim version of the headers (0x020013). It contains some corrections as well as some new definitions, (about 1000 or so) as well as about 50 new interface definitions. I have added a couple of header files that might be of use right away with Windows 7, the main one is the KnownFolders header file. Progress is slow with the headers because I am going over them definition by definition and making corrections as well as adding definitions that were omitted previously, this has turned out to be a very large task. The project will require the addition of nearly 100 new headers and somewhere around 10,000 new definitions when all is said and done. There are no changes or additions that will break current code.

Edgar

New upload with several new headers for Win7 as well as a few updated files, here's a synopsis:

Quotewindef.h // new types added

AdjustStack macro added, provides 32/64 bit cross compilation fix for c calls

Headers updated to Win7

accctrl.h // updated
aclapi.h // updated
aclui.h // updated
ahadmin.h // updated
ActivScp.h // new
commctrl.h // updated
ObjectArray.h // new
KnownFolders.h // new
propidl.h // new
propsys.h // new
propkey.h // new - format for property keys #DEFINE PKEY_name <FMTID GUID, pid> - PROPKEY struct will decode
structuredquerycondition.h // new
oaidl.h // updated
winuser.h // updated - Added CreateWindow support macro (no push/push/call support, only invoke)
wingdi.h // updated
wincrypt.h // updated
winerror.h // partially updated
winnt.h // updated
exdisp // updated
pidl.h // undocumented header - new
shlobj.h // updated

Since the core files have been completed, winuser, shobj, comctrl and winnt and wingdi, I have versioned this release as headers 2.1 (GOASMHDRVER = 0x021000)

An important change for shlobj.h as well as shobjidl.h is that all guid definitions have been moved to the shlguid.h header, this allows you to use the shell definitions without overloading the symbol table with guids. It really doesn't seem to make that much difference as GoAsm is more than adequate to handle them but I thought it might be a good idea.

Edgar

I had to manually define WINVER with the last update. I use :

#DEFINE WINVER NTDDI_WIN7ALL
#include windows.h

Was that change intended ?

Hi BlackVortex,

No, this change was not intended, I will look into it. There was a change to set the versions of common controls and shell based on the WINVER flag but it should not have had the effect you mentioned. My tests seemed to bear this out but I will do further testing and get back to you.

Edgar

Hi BlackVortex,

There was a dependency that I had missed in the winnt.h file that was causing it to fail if WINVER was not defined before Windows.h was loaded. This was a problem with the dependency chain, not winnt.h and was entirely due to my trying to tidy up the file a bit before I uploaded. I moved one line and retested but not as extensively as I should have. The problem has been fixed and a new upload is available, GOASMHDRVER = 0x021001.

Thanks for pointing it out, since I always specify OS version explicitly I might have gone some time before I found that one. If you do not want to download the whole project, the problem was in Windows.h and I have attached it here. Just replace Windows.h in version 0x021000 with this one.

I should explain how COMMCTRLVER and SHELLVER default definitions have changed, it is a rather important change. The versions are now set based on the value of the WINVER flag, the common controls and shell versions are set to the version number distributed with the Windows version specified. This is preferable to just setting them to the highest available version by default as it will automatically truncate structures to the size expected by whatever Windows version you supply and will limit the availability of certain ordinals to that version as well. This behavior can be overridden by specifying a value for the versions before including windows.h.

Edgar

Now it's back to normal. What is the default value for WINVER if I don't define it ?

Quote from: BlackVortex on February 05, 2010, 03:26:52 PM
Now it's back to normal. What is the default value for WINVER if I don't define it ?

NTDDI_WINXP

I have uploaded version 0x021004 to my website, it contains the fix described in the following thread to allow for an alternate syntax for COM calls:

http://www.masm32.com/board/index.php?topic=13308.0

Edgar

I have uploaded version 0x021005 to the website, it contains a number of additions to various header files as well as some corrections. This version marks the debut of the FILTERAPI switch that Yuri demonstrated the need for. API filtering will block the assembly of certain API calls based on the Windows version or DLL version supplied, for example if you specify WINVER = NTDDI_WIN2K all functions that do not natively ship with Win2K will report as follows:

QuoteThe following symbols were not defined in the object file or files:-
SomeApiFunction_NotAvailable

One notable exception to this is GDI+ which can be redistributed as far as Win98 so version 1.0 though not natively available below XP will be allowed. To override this behavior for a particular DLL and still use the API filtering you can explicitly set the required version of the DLL. For example to set common controls to version 6.1 (it will default to 5.82 even on Win7):

#DEFINE COMMCTRLVER WIN32_COMMCTRL_610

The predefined version constants are found in windef.h.

In order to distinguish between an API that doesn't exist and one that is not available to the windows version you specify _NotAvailable is appended to the API name.

I have not completed user32.dll or kernel32.dll yet, that may take some time as I am getting ready for a small trip on Tuesday but I will get to them when I return. I would really appreciate other contributions to this portion of the project as the more filtering that can be added the more effective WINVER will be, so if you'd like to pick a small DLL to write the filters for just check the API_Filter.h file to see how to do it.

Edgar

Edgar, my COM DLL exports a function called DllInstall. Now it's changed to DllInstall_NotAvailable. Maybe it'd be better to exclude it from version checking?

Quote
GoAsm.Exe Version 0.56.8 - Copyright Jeremy Gordon 2001/9 - JG@JGnet.co.uk

Error!
Line 185 of assembler source file (main.asm):-
Unknown mnemonic, instruction, redefinition or directive:-
DllInstall_NotAvailable
Defined in Line 27 of the include file API_Filter.h:
DllInstall  DllInstall_NotAvailable

Quote from: Platform SDK
This function may be implemented and exported by name by a DLL for use during application installation or setup. It is invoked by regsvr32 to allow the DLL to perform tasks such as adding information to the registry.

DllInstall is used only for application installation and setup. It should not be called by an application. It is similar in purpose to DllRegisterServer or DllUnregisterServer. Unlike these functions, DllInstall takes an input string which can be used to specify a variety of different actions. This allows a DLL to be installed in more than one way, based on any criteria that is appropriate.

Hi Yuri,

Darn, I was going to do that and thought I did, too many things between my main project, GDI+ tests and the headers, I have fixed it and uploaded again. Version has been incremented to 0x021006.

Thanks

Edgar

Edgar, GUID_IID_IDispatch remains undefined. First because the corresponding block is commented out in oaidl.h, and second, it should be placed outside of #IFNDEF IDISPATCH_DEFINED ... #ENDIF.

Thanks Yuri,

I will update it in the next release, it will just be an uncommenting of the def in oaidl.h and moving the guid definition:

#IFNDEF GUID_IID_IDispatch
#define GUID_IID_IDispatch <0x00020400,0x0000,0x0000,<0xC0,0x00,0x00,0x00,0x00,0x00,0x00,0x46>>
#ENDIF

#IFNDEF IDISPATCH_DEFINED
#IFNDEF IDispatch
IDispatch STRUCT
UNION
struct
QueryInterface PTR
AddRef PTR
Release PTR
ends
IUnknown Unknown
ENDUNION
GetTypeInfoCount PTR
GetTypeInfo PTR
GetIDsOfNames PTR
Invoke PTR
ENDS
#ENDIF
#ENDIF

I have uploaded version 0x021007 that contains some fixes to the problems that have been mentioned here and in other threads. The fixes are mainly to do with COM and the ability to make vTables. Here's the blurb from Windows.h:

QuoteThis has changed in version 0x021007

IDISPATCH_DEFINED
IUNKNOWN_DEFINED

You no longer must define these two switches in order to avoid
symbol conflicts in COM interfaces. They are defined in windows.h
and the definition can be overridden by the USE_IUNKNOWN switch.
If you do not define them the syntax for COM interfaces changes for
IUnknown and IDispatch implementations of all COM interfaces:

******************
With USE_IUNKNOWN only the following is valid

IInterface.QueryInterface

When setting up your vTable use the following syntax to fill
the IDispatch structure:

vtable IDispatch <<1,2,3>,<4,5,6,7>>

******************
Without USE_IUNKNOWN both of the following are valid (default)

IInterface.IUnknown.QueryInterface
IInterface.QueryInterface

the USE_IUNKNOWN switch will enable the definition of the IUnknown and IDispatch
interfaces. These are needed for COM servers in order to build vtables. They are
not available if the switch is not used. This was done in order to avoid symbol
conflicts and still keep both syntaxes.

As a result of the changes the unknwn.h header has been deprecated and simply loads the BaseCOM.h header, IDispatch and IUnknown are only defined in BaseCOM.h, redundant definitions have been removed from all header files.

Edgar

Thanks, Edgar! But I wonder why you still divided the alternative IDispatch into two parts? As they are unnamed, what purpose could it serve? After all the recent problems, I think the fewer levels of nesting, the fewer possible bugs (and also fewer brackets at initialization). The simpler, the better. As you have already said, it's not C++.  :wink

Hi Yuri,

I just prefer to separate them even though it makes little difference except in the declaration. Just a personal preference so it is clearer which parameter is which when I scan my code, makes for less counting parameters. No other reason than that and tests have shown that it performs exactly as expected so I saw no reason not to declare it that way.

Would be nice to have the header messages working again though...

Edgar

Uploaded an update to the headers, the current version is GOASMHDRVER = 0x021011, it includes a couple of new header files as well as some corrections. Also the api filter has been expanded to include the native API (ntdll.dll) versioned from Win2K to Win7. With Windows 7 the native API includes ordinal only exports for the first time, these have been included in a new header file called ntdll.h along with a few other undocumented structures and enumerations that might be useful. Still haven't begun work on user32.dll as far as versioning goes but hope to get to it soon as I have downloaded some excellent software that does a great job of comparing DLL exports (DiamondCS DLL Export Compare (http://diamondcs.com.au/developers/dllcompare.php)).

Edgar

Awesome, thanks for your work !   :thumbu

Thanks much to BlackVortex for the files I was missing.

I have uploaded GOASMHDRVER = 0x021012, it contains a fairly complete API filter file comprising 3045 API functions that have been added or deprecated from Win9x to Win7. To use the filter you specify your minimum OS version and define the FILTERAPI switch. Windows.h will set the version numbers for the libraries covered to whatever version was shipped with the OS you specify, you can override the library version by setting its version number directly, see Windows.h and windef.h for examples. In the case of GDI+ and ComCtl32, you will have to set the version number directly if you are using SxS DLLs. I may add libraries to the list in the future (perhaps gdi32) but for now I'm a bit sick of it so I'm taking a break. The following libraries are included:

GDI+
User32
Kernel32
NTDLL (Native API)
Shlwapi
Comctl32
Advapi (only parts of this library are included)
Iphlpapi
Shell32

These should comprise the libraries that have the largest changes from one Windows version to another and should allow fairly accurate versioning when developing applications. The only caveat is that I did not bother to do any versioning below Win2K, that is that all of the Windows 9x versions have been lumped together and there is no distinction made between them. However if you specify any 9x version it will filter functions that are only available to Win2K+.

Edgar

A small interim update before the weekend, I have completed the advapi32 versioning. Added a new type (ENUM) and will soon begin to update all the headers to reflect the new type, I think that it will make it clearer when reading a structure and trying to find the type of data that it requires (all enums are defined using name=value while constants use #define name value). Added a few structures to some files and added some new headers (security related).

EDIT: Just realized I forgot to merge the GDI32 api filters into the main distribution, I have just uploaded again with the updated API_Filter.h file that includes GDI32 filters up to Vista, since my laptop is out of commission for a while and it was the only Win7 box I had I don't have a copy of GDI32 for Windows 7 and couldn't version that DLL.

Edgar

GOASMHDRVER = 0x021014 has been uploaded, it contains the complete DirectShow headers along with DirectSound and a few updates to some other headers. Also added are the external device headers for controlling things like VCR's and DVD's as well as the headers for WPC (Windows Parental Controls), Windows Event Tracing and the MacIntosh Win32 code porting header. The only note for the added headers is for strmif.h:

Quote from: strmif.hNOTE:

The VMRGUID structure has the following change:

The member VMRGUID.GUID has been changed to VMRGUID.guid to resolve a conflict with the GUID structure

Also available are the internal GDI direct draw functions which are exported as GdiEntry(x), the headers will translate them to the documented names automatically (i.e. DdCreateDirectDrawObject). Usage for the functions is available here (http://msdn.microsoft.com/en-us/library/ms648408%28VS.85%29.aspx#_dxgkernel_functions), the following functions are supported:

DdCreateDirectDrawObject
DdQueryDirectDrawObject
DdDeleteDirectDrawObject
DdCreateSurfaceObject
DdDeleteSurfaceObject
DdResetVisrgn
DdGetDC
DdReleaseDC
DdCreateDIBSection
DdReenableDirectDrawObject
DdAttachSurface
DdUnattachSurface
DdQueryDisplaySettingsUniqueness
DdGetDxHandle
DdSetGammaRamp
DdSwapTextureHandles
DdChangeSurfacePointer << undocumented

Edgar

MILESTONE: The header project has now passed 5 MB, consisting of 395 files.

I have uploaded version 0x021016 to my website, it contains the following changes:

QuotePROPVARIANT structure added to propidl.h
Correction to the VARIANT structure for Win64, bstrVal is now defined as a PTR
Filter api added
Structured Query api added
Windows Desktop Search api added
Corrections to various structures (note that I may not have caught them all)
Corrections to Win64 DLL names (this problem was due to some tests I was running and was uploaded in error)
macros.a has been removed from the distribution (this file has been deprecated for some time)

It should also be noted that the error in the structures only occurs when the DUP operator is used, see E^cube's post (http://www.masm32.com/board/index.php?topic=14130.0) for further information.

Note that as of this version macros.a is no longer in the distribution, use macros.h instead.

Edgar

After a long gap from Assembly Language programming, I made a long visit to "Donkey's Stable".  I was very impressed with what I saw.

Thanks.

Quote from: Dharam on June 24, 2010, 11:33:57 PM
After a long gap from Assembly Language programming, I made a long visit to "Donkey's Stable".  I was very impressed with what I saw.

Thanks.

Well thank you very much Dharam, I'm glad you like the code and hope you might find some useful or at least helpful.

Edgar

Hi, Edgar

For APIs like DialogBox that are actually macros, I thought it might be useful if they resolved into something like DialogBox_IsMacro. Or even, for more clarity, DialogBox_IsMacroForDialogBoxParam?  :lol

These are in winuser.h:

Quote
DialogBox —> DialogBoxParam
DialogBoxIndirect —> DialogBoxIndirectParam
CreateDialog —> CreateDialogParam
CreateDialogIndirect —> CreateDialogIndirectParam

Hi Yuri,

We have discussed incorporating these types of macros in the past...

http://www.masm32.com/board/index.php?topic=11130.msg91477#msg91477

I will consider adding them but I tend to leave these types of macros for each person to write and use themselves, that way they have control over any code generation and can more easily track down bugs.

Edgar

Hi, Edgar

No, I didn't mean writing any macros, only clarifying the situation. When GoLink could not find DialogBox, it took me some time to figure out that DialogBox isn't actually a function and isn't exported by any Windows DLL.

I meant the same as what is done by API_Filter.h:

FlatSB_EnableScrollBar_NotAvailable

If someone tried to call DialogBox in his code, I think it would be good if he saw something like:

Error!
The following symbol was not defined in the object file or files:-
DialogBox_IsMacroForDialogBoxParam


That would help him understand what is wrong and what to do.

Although I'm not sure, maybe DialogBox and the other three were real functions on some previous Windows (I am using XP)?

Hi Yuri,

This could easily be done through the API filter header, if you will submit a list of the API's you want warnings for I will add them to the next update.

Edgar

Hi, Edgar

At the moment, I only have the four mentioned above.

Hi Yuri,

I will add the following to API_Filter.h

// Winuser.h macros that are not supported
#DEFINE DialogBox DialogBox_MacroNotSupported
#DEFINE DialogBoxIndirect DialogBoxIndirect_MacroNotSupported
#DEFINE CreateDialog CreateDialog_MacroNotSupported
#DEFINE CreateDialogIndirect CreateDialogIndirect_MacroNotSupported

It will be included in the next update on Sunday.

Edgar

It's been a while since the last update, sorry but I've been quite busy lately. I have uploaded headers version 0x021019. It includes the filters Yuri requested above as well as some expansion of the Winternl.h file that I needed for my profiler project. There are also a few corrections but no new additions.

Note that much of the expansion to Winternl.h are undocumented equates and structures for Ntxxxxx functions so use them at your own risk.

Hello all,

I have finally got around to making some corrections in the headers as well as a few additions. Special thanks to Ramon Sala for his bug reports. winerror.h has been entirely regenerated, there was a mistake in the automated search and replace that caused any error number ending in 5 to be incorrect, I found it easier to scrap the old file completely and regenerate it from the Windows 7 header directly. A few other files have also been corrected (mmsystem.h and acctrl.h to name 2). I have included the headers for RadAsm 3 and moved them to a separate folder along with the RadAsm 2 header. The files are no longer switchable in Windows.h, you will have to modify any existing software to reflect this. The paths for #including them are:

#include "Radasm\AddIns.h" ; for RadAsm 3.x
#include "Radasm\RadAsm.h" ; for RadAsm 2.x

I have uploaded version 0x021022 to my website

Edgar

This is a very minor update but contains a critical fix to the ACCEL structure. The ACCEL structure needs to have all of its members aligned on WORD boundaries and even though the fVirt member is identified as a BYTE in the MSDN headers it was changed to WORD in this version. All API's that use this structure will fail without this change. There were also some additions to the winternl.h file for a project I am working on, structures and equates for NtQueryInformationFile have been added.

New upload is GOASMHDRVER = 0x021024

A minor update, there was some interest in sqlite so I have included the headers for that library in the general headers package, sqlite3.h and sqlite3ext.h have been included. sqlite3ext.h is meant for use with a static lib version of the library, it defaults to the name libsqlite3.lib however that is modifiable using #DEFINE SQLITELIB xxxx.lib, it should not be included if you are using the DLL version, sqlite3.h contains the structures and equates necessary to build sqlite applications. I do not have a static lib version of sqlite that is usable from GoAsm so I have not included it in the libs folder, when I find or build one I will distribute it with the headers. Also there were a couple of minor corrections to 64 bit structures, some PTR members were still defined as DD in commdlg.h.

New upload is GOASMHDRVER = 0x021025

Uploaded version 0x021028, it contains a few additions to Winternl.h as well as a lot of additions to shlwapi.h to bring it up to date with Windows 7. Some other minor edits, i have started to change duplicated structures but it will take a while to get them all. The API filter messages have been changed to include spaces to make them more readable (well not really spaces but character 255) so filter error messages now look like this:

QuoteError!
The following symbol was not defined in the object file or files:-
DialogBox (Macro Not Supported)
Output file not made

Error!
The following symbol was not defined in the object file or files:-
ImageList_DestroyShared (Not Available)
Output file not made

Error!
The following symbol was not defined in the object file or files:-
RtlCompareVariants (Deprecated)
Output file not made

Error!
The following symbol was not defined in the object file or files:-
DefSubclassProc (Ordinal only export)
Output file not made

Its a little easier to read without the underscores I think. As always define the FILTERAPI switch to enable API filtering and set WINVER to the minimum supported OS you need, default is Windows XP no service pack.

Edgar

Uploaded version 0x02102A, there are several small corrections and updates for WIN64, the most significant is the CoInvoke macro found in macros.h. I had tested it but never ran into a method with more than 2 or 3 parameters and was under the impression that it worked, it didn't. Luckily I haven't gotten any feedback about it so nobody ran into the ceiling as I did today. There were several problems with the macro, starting with the 5th parameter (since *this is one parameter it appears to be 4) the values have to be pushed right to left also the stack allocation for the shadow registers has to come after all the pushes are done, the pushed parameters also have to be cleaned off the stack. These issues have been dealt with and it is tested and works fine.

Uploaded version 0x02102B, the only significant change was to the 64 bit version of the CoInvoke macro. There was an issue with inline strings in the first 3 parameters, since FASTCALL requires that the string pointers be moved into a register the CoInvoke macro required that you use OFFSET. I have eliminated this by using push/pop for the registers, that puts in a bit of bloat but not much (~3 bytes per parameter). It also demonstrated an issue in GoAsm 32 bit that involved using a * in inline strings when OFFSET was used, Jeremy is looking into the problem.

New upload (GOASMHDRVER = 0x02102E), a few changes to various header files, mostly technical that will not affect any usage but makes future expansion easier. Added the readgsqword and writegsqword macros to macros.h. Added dwmapi.h for the Desktop Windows Manager interface.

Note that the DWM api is available from Vista onward and if you are using the FILTERAPI switch the functions will not be available unless WINVER is set to NTDDI_VISTA or higher. The readgsqword and writegsqword macros are available only in X64 mode.

Great contribution ones again donkey :U

Normally I would just change my message, but since I was the last to reply and me having a new question I am replying with a new message.

You're doing a phenomenal job Edgar.

I was wondering are you using a tool to convert the header files into files GoASM can read or are you doing it all by hand?.

Hi FlySky,

Sorry for the late reply, I was out camping in the mountains for the last 2 weeks and just got home. I translate all headers by hand, that way I have more control over syntax and structure.

Its been a while since there's been any updates to the headers. I've uploaded an interim update since some projects I've been working on require some that weren't included. Since the main headers have yet to be finished I haven't incremented the version number as of yet. Notable additions in this one are the Direct3D 9 headers and also VMR9. You can download them from my website.

Edgar

I've noticed a small problem with the windef.h file, if WIN64 is not defined before it is included it will use 32 bit types. Attached is the corrected windef.h, or you can just make sure that you define WIN64 in your source. Any future updates will include the fixed windef.h.

Edgar, the use of the WIN64 switch in the headers seems to me a little confusing. It is not defined in windows.h before other headers are included, so it's not obvious whether it is on or off. Whether I have to define it myself or not. What do you think about putting its definition (depending on #if x64) in the beginning of windows.h?

Hi Yuri,

In my current working headers WIN64 is defined in windef.h, your suggestion is better and I will move it to Windows.h. The next header update is still some ways off due to bitfield issues that have been discovered, translating all direct draw headers up to and including 11 and starting ont he Windows 8 definitions. It is taking more time than I expected to get the job done.

Edgar

Hi, Edgar

I have just searched for the definition of CRITICAL_SECTION and it seems that though members of some structures in atlbase.h are defined as CRITICAL_SECTION <>, but CRITICAL_SECTION itself isn't defined anywhere in the headers. I could only find RTL_CRITICAL_SECTION in winnt.h.

Also, all the members of RTL_CRITICAL_SECTION are difined as DD. I think it should be:

RTL_CRITICAL_SECTION STRUCT
    DebugInfo PTR
    LockCount DD
    RecursionCount DD
    OwningThread HANDLE
    LockSemaphore HANDLE
    SpinCount ULONG_PTR
ENDS


Hi Yuri,

Thanks, I'll take a look at it on the weekend.

Hi Yuri,

I had some time to look into CRITICAL_SECTION, it is defined in SDK 7.1 in the WinBase.h file as

typedef RTL_CRITICAL_SECTION CRITICAL_SECTION;

So you can use RTL_CRITICAL_SECTION in its place although as with many structures of this type the size is all that's important, there seems to be no practical use for knowing the member values. Also your version of the structure is correct, it must have slipped through in the 64 bit edits. The corrected structure and the equate will be in the next release of the headers. Since GoAsm does not assemble 16 bit applications the other typedef's I found will not be added because as far as I can see they apply only to DOS programs i.e. from MAPIWin.h:

#define   CRITICAL_SECTION         ULONG

Edgar

Great work as always donkey.
I've got a small question though.
I am trying to translate a couple C/C++ header files to work with GoASM.

I've got these lines for example:
typedef void* (*FactoryFn)( const char *pName );

and the project contains classes.
class GetGameID
{
public:

   //-----------------------------------------------------------------------------
   // Purpose: Constructor
   //-----------------------------------------------------------------------------
   GetGameID()
   {
      m_gameid.m_comp.m_unAccountID = 0;
      m_gameid.m_comp.m_EAccountType = k_EAccountTypeInvalid;
      m_gameid.m_comp.m_EUniverse = k_EUniverseInvalid;
      m_gameid.m_comp.m_unAccountInstance = 0;
   }

Basicly the question how can the above class (header) be translated.

Hi FlySky,

Sorry but I have no idea, sort of looks like a Java class but without the complete file its hard to tell. Can you zip and post the header file and I'll take a look at it.

Edgar

#ifndef ISTEAMAPPS002_H
#define ISTEAMAPPS002_H
#ifdef _WIN32
#pragma once
#endif

#include "SteamTypes.h"
#include "AppsCommon.h"

//-----------------------------------------------------------------------------
// Purpose: interface to app data
//-----------------------------------------------------------------------------
abstract_class ISteamApps002
{
public:
   virtual bool BIsSubscribed() = 0;
   virtual bool BIsLowViolence() = 0;
   virtual bool BIsCybercafe() = 0;
   virtual bool BIsVACBanned() = 0;

   virtual const char *GetCurrentGameLanguage() = 0;
   virtual const char *GetAvailableGameLanguages() = 0;

   // only use this member if you need to check ownership of another game related to yours, a demo for example
   virtual bool BIsSubscribedApp( AppId_t nAppID ) = 0;
};


#endif // ISTEAMAPPS002_H

It's from OPENSTEAMWORKS an opensource project which allows you to code steam applications.
Is it possible to use a .lib file to use the functions.
Basicly when compiled it uses some sort of VTABLE to call the right function.

Hi FlySky,

I generally do not translate the class objects, they are not particularly useful when accessing the interface and unless you are translating the DLL to GoAsm they are not something you would ever access. The vTable on the other hand is critical as well as the CLSID and IID for the interface. Under normal circumstances the data defined in the class object is unavailable to programs using the interface, you simply create an instance of the class and treat it as a "black box", that is you let it handle the internal class data. I will take a look at the header though.

Edgar

I couldn't follow it completely.
A Class Object is compiled into a Vtable.
Than in C++ you would acces the right function in the Class
by using something like Client *ISteamApps002 = BIsSubscribed();
right?

Hi Flysky,

Not exactly, the vTable is just a single component of the class object, it is usually defined separately as an interface, not with the class. A class object also contains pointers to vTables, variables, working data, and fixed data that are needed when an instance of the class is created. This data is generally reserved for use by the class and is not meant to be accessed by programs instantiating it. For this reason I normally find that there is little gained by actually defining the class object itself except ofcourse if it is your own class and you are writing a COM server application.

I will see if I can pick up a C++ book to give me a better understanding, this doesn't make much sense yet :bg

Hi Flysky,

This article (http://www.cs.umd.edu/~pugh/com/) isn't bad, it explains the differences between classes (actually coclasses since they are not the same as C++ classes) and interfaces. It can be a bit hard to wrap your head around at first but once you get it you'll find that COM is actually not too bad and a remarkably easy way to implement very complex functions and even easier to use than straight API programming if you want a lot of bang for a little code. And by the way, it can make your code a pain in the arse to reverse engineer since it does not use many named APIs.

Your confusion is pretty well dealt with in the "Attributes of Interfaces" section of the article I posted, pay special attention to that section, specifically "An interface is not a class".

i am trying to work up some bravery to play with it, Edgar   :bg
i was also thinking i might play with GoAsm, just so i could read all your examples

Thanks for the information Edgar. I will try to wrap my head around it  :U