fbits RECORD order

[redskull]

I've seen some confusion on this before, and I did try previous posts, but forgive me for not understanding.  When using the RECORD directive, the MASM programmers manual says that the first field goes into the most significant bit, and continues to the right towards the least significant.  I try and configure a serial port handshaking using the following declaration:

Code Select Expand

mybits BITRECORD <1,1,0,0,01,0,0,1,1,0,1,00,0>
where

Code Select Expand

BITRECORD RECORD fBinary:1,fParity:1,fOutxCtsFlow:1,fOutxDsrFlow:1,fDtrControl:2,
fDsrSensitivity:1,fTXContinueOnXoff:1,fOutX:1,fInX:1,fErrorChar:1,fNull:1,
fRtsControl:2,fAbortOnError:1,fDummy2:17
which gets put into the DCB structure  as {00 00 D0 C4}, which seems accurate enough. (the 17 'padding' fDummy2 bits get put in the lowest spots)  However, the configuration doesn't work as expected (specifically the software handshaking).
So then I fire up hyperterminal and change the settings (and then test them working), and use GetCommState to figure out what they were.  Everything else is the same but the fbits DWORD, which hyperterminal configured as {91 53 00 00}, which doesn't seem right because it's in the wrong way (the most significant bits are all zeros).  Am I declaring things wrong, is the record declaration backwards, am I analysing things wrong, or is it a combination of all three?  My brain is about fried looking at all the zeros and ones, forwards and backwards; could someone point me in the right direction?

alan

[ToutEnMasm]

Hello,
Perhaps more information can help ?

DTR_CONTROL_DISABLE   equ   <000h>
DTR_CONTROL_ENABLE   equ   <001h>
DTR_CONTROL_HANDSHAKE   equ   <002h>
;
; RTS Control Flow Values
;
RTS_CONTROL_DISABLE   equ   <000h>
RTS_CONTROL_ENABLE   equ   <001h>
RTS_CONTROL_HANDSHAKE   equ   <002h>
RTS_CONTROL_TOGGLE   equ   <003h>

MASMBITRECORD   RECORD fBinary: 1  ; Binary Mode (skip EOF check)    ,\
   fParity: 1  ; Enable parity checking          ,\
   fOutxCtsFlow:1  ; CTS handshaking on output       ,\
   fOutxDsrFlow:1  ; DSR handshaking on output       ,\
   fDtrControl:2  ; DTR Flow control                ,\
   fDsrSensitivity:1  ; DSR Sensitivity              ,\
   fTXContinueOnXoff: 1  ; Continue TX when Xoff sent ,\
   fOutX: 1  ; Enable output X-ON/X-OFF        ,\
   fInX: 1  ; Enable input X-ON/X-OFF         ,\
   fErrorChar: 1  ; Enable Err Replacement          ,\
   fNull: 1  ; Enable Null stripping           ,\
   fRtsControl:2  ; Rts Flow control                ,\
   fAbortOnError:1  ; Abort all reads and writes on Error ,\
   fDummy2:17  ; Reserved       

DCB   STRUCT
   DCBlength DWORD ?  ; sizeof(DCB)                     
   BaudRate DWORD ?  ; Baudrate at which running       
   MASMBITRECORD <>
   wReserved WORD ?  ; Not currently used             
   XonLim WORD ?  ; Transmit X-ON threshold         
   XoffLim WORD ?  ; Transmit X-OFF threshold       
   ByteSize BYTE ?  ; Number of bits/byte, 4-8       
   Parity BYTE ?  ; 0-4=None,Odd,Even,Mark,Space   
   StopBits BYTE ?  ; 0,1,2 = 1, 1.5, 2               
   XonChar BYTE ?  ; Tx and Rx X-ON character       
   XoffChar BYTE ?  ; Tx and Rx X-OFF character       
   ErrorChar BYTE ?  ; Error replacement char         
   EofChar BYTE ?  ; End of Input character         
   EvtChar BYTE ?  ; Received Event character       
   wReserved1 WORD ?  ; Fill for now.                   

DCB      ENDS
               

[redskull]

Some more confusion:  instead of manually setting the fbits, i used the BuildCommDCB function, with the same results.  the fbits returned by both the BuildCommDCB and the hyperterminal configuration were both in the order of 'nn nn 00 00', whereas setting the bits manually using the BITRECORD directive did it in the order of '00 00 nn nn'.  the very first bit (fBinary) should always be 1, so what am I doing wrong?  If the bit record is stored most-to-least significant, then how are the first 16 significant bits of the structure returned by the windows function all zeros?  I must be initializing the manual bitrecord wrong, but I still can't see why.

invoke BuildCommDCB results: (10 03 00 00)
0000 0000 0000 0000 0000 0011 0001 0000

mybits BITRECORD <1,1,0,0,1,0,0,1,1,0,1,1,0,0> results: (00 00 D4 C4)
1100 0100 1101 0100 0000 0000 0000 0000

alan

[MichaelW]

The problem was discussed here here, but AFAIK was not solved.

[redskull]

at least it's good to know i'm not going crazy.

[redskull]

It's not really an official reference, but in http://msdn2.microsoft.com/en-us/library/aa446551.aspx, the author talks about using the DCB structure with something sort of .NET framework or something, but he goes on to say:

"The native DCB structure is a bit of a challenge to implement because it has 13 settings packed into the lower 15 bits of a DWORD."

The MASM programmers manual says that the first element of a RECORD is placed in the most significant bit, and works it's way down.  Does a bit record in VC++ get stored backwards than MASM?  I called MS, but they wanted like $250 bucks for the answer.

***edit***

from http://msdn2.microsoft.com/en-us/library/ewwyfdbe.aspx

"The ordering of data declared as bit fields is from low to high bit, as shown in the figure above."

from the MASM programmers guide:
"The first field in the declaration always goes into the most significant bits of the record. Subsequent fields are placed to the right in the succeeding bits"


Does this mean that the fbits should be reversed in the WINDOWS.INC?

alan

[zooba]

Does this mean that the fbits should be reversed in the WINDOWS.INC?

That was actually the first thing I thought of when I read this. I went looking for a reference and got sidetracked. Sounds like you've done all the research and have the right answer though, easiest thing to do now is try it and see :bg

Cheers,

Zooba :U

[redskull]

does this mean all the RECORD's in windows.inc need to get changed?