Problem with windows.inc

[absolutzero]

I d like to thank for masm32 project, especially for unicode support. But I found problems with windows.inc, which causes errors in assembling.

First problem is in DRAWTEXTPARAMS STRUCT. There is item iTabiLength, but Microsoft defines it iTabLength.

Also I have problem with lfFaceName WORD LF_FACESIZE dup (?) item in LOGFONTW structure in unicode project. I changed it to: lfFaceName BYTE LF_FULLFACESIZE. I dont know, if it is syntactically right, but it works.

[hutch--]

Its likely to be a typo from long ago and changing it is the right response.The file was produced back when the reference material was very hard to find and while most of the errors were fixed long ago, you still get the odd quirk that has been missed.

[rsala]

Hi,

For the UNICODE version (LOGFONTW), the lfFaceName member must be "lfFaceName WORD LF_FULLFACESIZE dup (?)". "lfFaceName BYTE LF_FULLFACESIZE" is for the ANSI version (LOGFONTA).

[absolutzero]

Thanks for replies. I played with LOGFONTW again and it seems, that its declaration in windows.inc is ok. Problem is rather in its initialisation:

.data
logfnt          LOGFONT <-13,0,0,0,FW_NORMAL,0,0,0,DEFAULT_CHARSET,3,2,1,49,"Lucida Console">

My fix lfFaceName BYTE LF_FULLFACESIZE is assembled without errors, but font name is compiled as ANSI, not UNICODE string. I dont know, how to initialise this structure. I think the best solution of this is move structure to unitialised data section and initialise it at runtime:

.data?
logfnt          LOGFONT <>

[Biterider]

Hi
Try this

Code Select Expand

.data
logfnt          LOGFONT <-13,0,0,0,FW_NORMAL,0,0,0,DEFAULT_CHARSET,3,2,1,49,{"L","u","c","i","d","a"," ","C","o","n","s","o","l","e",0}>

Biterider

[TouEnMasm]

see generator of fonts
http://masm32.com/board/index.php?topic=648.msg5310#msg5310

[absolutzero]

Biterider thank you, it works.

[jj2007]

There is another little glitch in WinExtra.inc, see http://masm32.com/board/index.php?topic=9890.msg108391#msg108391

Strangely enough, ML.exe, UAsm and earlier AsmC versions never complained about it.

[hutch--]

As you may appreciate, producing include file for 32 bit MASM is something like picking fly sh*t out of pepper with a blindfold on and using a blunt pair of pliers to do it. 32 bit MASM is reasonaly picky about what it will accept and 64 bit MASM is a genuine pig to create working include files for.

The testimony to the joys of making include files for MASM is the number of people who have copied them for other assemblers. 

[jj2007]

Another testimony to the joys of making include files for MASM is the number of people who have tried (more or less successfully) to produce their own set of includes from various C compilers' header files. You did a pretty good job, Hutch, the glitch I reported is the first in a number of years