Headers 2.0

[Mark Jones]

I'm still working on the updated templates, and have ran into a quandary. For 32-bit applications on a 32-bit OS, OllyDbg seems to be a good contender as a blanket "$E" RadASM (GoASM.ini) definition. However, OllyDbg will not run on a 64-bit OS, so it therefore cannot be used as "$E" in all cases. Trying to make the templates 64-bit compatible, this is proving to be an issue.

I cannot see a good solution to this in terms of a template, because each template defines the command explicitly and statically. I considered if "$E\Debug.exe,5" were used instead, and the user renamed their 32 or 64-bit debugger executable to "Debug.exe", but this still does not address the issue that RadASM does not know if the user is on a 64-bit OS or not, and does not know that only certain debuggers will work in 64-bits.

Perhaps what is needed is an additional debugger definition in RadASM, "$64" lets say, which points to the 64-bit debugger. Also, define (under [Paths] in GoAsm.ini) "$E" and "$64" to include the filename, i.e. "$E=\Coding\OllyDbg\OllyDbg.exe". Then, for an added touch, have RadASM determine upon startup, if the user is running on a 64-bit OS, and define "$debugger" as either "$64" or "$E"... therefore, "$debugger,5" will work in all templates, for all users, and they must only define the paths to their debuggers in GoAsm.ini.

Does this sound like a good proposition to ask KetilO to consider?

[Kernel]

However, OllyDbg will not run on a 64-bit OS,

It does so on Vista64 at least. Of course not for x64 processes, but for x86 ones.
Sry I don't know about XP64, but in any case you would need this olly plugin:
http://www.tuts4you.com/download.php?view.2425

cheers

[donkey]

For the next few months I have to set the headers project aside while I concentrate on work. I will still be sure to correct any errors brought to my attention but new header files are pretty much out the question for a while. If anyone wants to contribute to the project I will add their headers to the main project once they are posted here and vetted by the group. The rules are simple, follow the naming conventions at MSDN as closely as possible and also the conventions already established in the header project. This is mainly so we don't end up with a mish-mosh of different naming standards and file names. If you are uncertain as to how to implement a certain header just post your questions and ideas here for group discussion. Since the header project is now the "de-facto" standard for GoAsm includes I am turning its design and goals over to the group though I hope to be able to contribute more headers once my busy time is over. As for answering questions I will still try to do at least that but I am not always near a computer or internet access so I may not get to them right away, Mark Jones, E^cube and a few others know as much as I do about the headers and their usage so they will probably be better placed to give prompt answers than I.

[donkey]

There are a few headers that I think should be translated, they are IMO important to make the header collection complete but I never got around to either starting them or finishing them. Though I don't have the time myself it would be helpful if someone could tackle the following header files:

SAPI - sapi.h and sapi51.h
DirectX - all current versions (including Direct3d, DirectSound and DirectPlay)
msxml2.h and msxml6.h

These are generally COM headers and would require a working knowledge of COM.

Also, this project respects copyrights, any translation should have the original copyright notice in the file or be covered by one of the blanket notices in Windows.h. Under no circumstances should you include a personal copyright notice in a translated file as I believe it attempts to abrogate the rights of the original author, if you add content to a header you can include a "portions of this file copyright..." notice.

[donkey]

Well, I'm back home for a couple of days and looked through my emails and to my disappointment did not find any volunteers for translating the header files. I am really hoping that some-one will step up and do a couple of them.

[dedndave]

i saw a program that converts .h into .inc
let me see if i can find it...

[dedndave]

here it is on Wayne's site.....

http://www.magma.ca/~wjr/xlatHinc.zip

even if it doesn't do a 100% job, it should save a lot of work

[BlackVortex]

What about japheth's h2incx ?
http://www.japheth.de/

[ecube]

Donkey decided to go against automatic translation because it seems to lose something, and possibly miss some things. He also has a format that he follows and has outlined earlier. I would try and help translate headers myself but my times consumed as is, and my priority first is to get the new SDK out. I really hope someone steps forward though, and helps donkey out, he's given countless hours i'm sure with the existing headers, it'd be nice if he got something back.

[dedndave]

still, for larger files, i would think you could use one of the translator porgrams, then do clean-up
i suppose another approach would be to write a new translator
certainly, the time spent would pay for itself
you might even be able to get the source from Wayne or Japeth so you don't have to re-invent the wheel

[donkey]

Because of some issues I have with the existing translation programs, mainly the inability to modify naming conventions and in the case of MASM targeted ones some incompatibilities that are sometimes difficult to find and edit out I had decided against the automated approach. I had planned to look at Dacorbi Pattern Search and have obtained permission from the author to use it for free to translate the headers but time ran out and my busy season started before I could get started. I am sure that with Dacorbi a conforming translator could be written since it is scripatble. That said, as long as the conditions above are met anything you use would be OK with me.

PS I am sorry if my responses sometimes seem out of sync with the current discussion but I am out of town very often now (I have only been home 9 days in the last 2 months) and I rarely have much in the way of internet access except a cell connection which is far too expensive to use for browsing the forum...

[Yuri]

Edgar, there are two structures in WinCon.h that probably use too small types (should be DW):

Code Select Expand


COORD STRUCT
X DB
Y DB
ENDS

SMALL_RECT STRUCT
Left DB
Top DB
Right DB
Bottom DB
ENDS

From MS's wincon.h:

Code Select Expand


typedef struct _COORD {
    SHORT X;
    SHORT Y;
} COORD, *PCOORD;

typedef struct _SMALL_RECT {
    SHORT Left;
    SHORT Top;
    SHORT Right;
    SHORT Bottom;
} SMALL_RECT, *PSMALL_RECT;


[donkey]

Thanks Yuri,

The correction has been made in version 0x020010 and has been uploaded.

Code Select Expand

COORD STRUCT
X SHORT
Y SHORT
ENDS

SMALL_RECT STRUCT
Left SHORT
Top SHORT
Right SHORT
Bottom SHORT
ENDS

[ramguru]

LVITEM & LVCOLUMN structures are wrong in x64,
padding missing.

Code Select Expand


LV__COLUMN STRUCT
  mask      dd
  fmt      dd
  cx      dd
     dd ; PADDING !
  pszText    dq
  cchTextMax dd
  iSubItem   dd
ENDS

LV__ITEM STRUCT
  mask      dd
  iItem      dd
  iSubItem   dd
  state      dd
  stateMask  dd
     dd ; PADDING !
  pszText    dq
  cchTextMax dd
  iImage     dd
  lParam     dd
  iIndent    dd
ENDS



[wjr]

It is not necessary to explicitly define this padding with GoAsm. Due to stricter Win64 alignment requirements, GoAsm automatically handles this padding for proper alignment (also making 32/64-bit structure definitions easier to maintain).