windows 10 abend

[nedman47]

The code below runs in Windows 7 but not 8.1 or 10.

The program writes its line of text then crashes with the usual unhelpful windows message that the program has stopped responding.

FBdebugger says WriteConsoleOutputCharacter is trying to write to location zero.

Am I using the wrong library?

Code: Select all

#INCLUDE "windows.bi"

dim Colr As Long
dim hStdOut As Handle
dim ul As Coord
dim as string txt
dim as long row, col, fgcolr, bgcolr

txt = "what hath god wrought"

fgcolr = 14
bgcolr = 6
row = 12
col = 40

Colr = BgColr * 16& + FgColr
ul.x = col - 1
ul.y = row - 1

hStdOut = GetStdHandle(STD_OUTPUT_HANDLE)
WriteConsoleOutputCharacter hStdOut, Txt, Len(Txt), ul, 0
FillConsoleOutputAttribute hStdOut, Colr, Len(Txt), ul, 0

[Zippy]

The functions as you've called them are trying to write to location zero.
The last parameter for both the Write and Fill functions is defined:

_Out_ LPDWORD lpNumberOfCharsWritten

...a pointer to a var. When you spec "0" you are pointing to location zero.
Why Win10 (tested Win7/Win10 32/64-bit) tosses this? Win10 more pedantic?

Corrections:

Code: Select all

dim as integer numcharwritten
...
WriteConsoleOutputCharacter hStdOut, Txt, Len(Txt), ul, @numcharwritten
FillConsoleOutputAttribute hStdOut, Colr, Len(Txt), ul, @numcharwritten

.
Always odd that the functions don't require a pointer to the COORD (@ul), but then the console subsystem is old code...
.

[venom]

Well, the msdn doesn't mention passing a nullptr for lpNumberOfCharsWritten is allowed, so I guess this is an excellent example of relying on undefined behavior. This kind of stuff usually kicks you in the butt when you least expect it, so better stick to the documentation. :)

[nedman47]

Thanks to those who answered my last question.

This time I'm trying to compile the same code with the 64 bit compiler and I'm getting a warning at the same pointer.

warning 3(1): Passing different pointer types, at parameter 4 of WRITECONSOLEINPUTA()

here is my code:

nRet = WriteConsoleInput(_
hStdIn,_
cast(PINPUT_RECORD,@InputRec(0)),_
UBound(InputRec) + 1,_
@EventsWritten)

and here is what MSDN has for that function:

BOOL WINAPI WriteConsoleInput(
_In_ HANDLE hConsoleInput,
_In_ const INPUT_RECORD *lpBuffer,
_In_ DWORD nLength,
_Out_ LPDWORD lpNumberOfEventsWritten
);

Can someone explain this?

Even better would be a reference to better understanding of how to translate C pointer into Freebasic.

Thanks in advance.

[D.J.Peters]

if you need help you have to post the whole code
how we should know what EventsWritten is in your code ?

for exmple integer is wrong it's 8 byte on 64bit
you need a pointer to a 4 byte unsigned int (DWORD)

try

dim as ulong EventsWritten

Joshy

[nedman47]

Yes, that was it. Integer changes size depending on the compiler.

This could cause some nasty and hard to find bugs.

The FB wiki says this about the integer type:

Syntax:
dim variable as Integer
dim variable as Integer<bits>

Parameters:
bits
A numeric constant expression indicating the size in bits of integer desired. The values allowed are 8, 16, 32 or 64.

I tried integer<bits> but got a syntax error. Maybe this has not been implemented yet.

It seems to me it would be a good idea to nail down the sizes like that. This is the kind of misunderstanding that leads to buffer overflows in crypto.

[dkl]

Here's an example that should work:

Code: Select all

dim i32 as integer<32>
print sizeof(i32)

Plain Integer is the only type in FB that changes its size depending on platform or -lang mode, the others are fixed-size. Check out TblVarTypes

[D.J.Peters]

@dkl I miss ENUM as data type in the table you pointed.

I mean sizeof(ENUM) and the behavior on 32/64-bit OS
or is it documented on a other page ?

Isn't on the KeyPgEnum

Joshy