Michael, I agree that the cpu would not be the problem ,unless it has a need to have cpu cycles yielded to it. I don't seem to be able to get an answer on that. Under Windows, and running on a multicore processor, if you max out your process priority, so no other (user) process will be able to pree...

I have doubts that the CPU is the problem, because it's much, much faster than your I/O board.

For example, the FB graphics window (Screen[Res]) on Windows takes characters in the system codepage and then explicitly converts them to CP437 (the DOS/OEM codepage...) Unless this detail has changed, the character pixel patterns used in the graphics modes were captured from a VGA BIOS, that I thi...

_WIN32_WINNT >= Ox0501 specifies Windows XP or later, so considering how few people are running pre-XP systems the last member should probably be included in the size by default.

If a variable is stored on the stack, whether because it's a local variable allocated from the stack, or it's passed on the stack as a procedure parameter, it's going to occupy 4 or 8 bytes regardless.

I think under Windows CondWait and related functions are based on the Windows Wait Functions, so perhaps the Microsoft descriptions may make more sense.

The FreeBASIC fonts include the entire character set, and are the VGA pattern. I'm not sure what your display requirements are, but you could render your characters to an appropriate image buffer (ImageCreate), BSAVE the buffer to a bitmap, then display the bitmap in a static control. Forcing the us...

Looking at the 1.04.0 source, in fb_gfx_private.h, the FB_GFXCTX (fb_gfx context) structure stores the foreground and background colors as separate 32-bit unsigned integers: typedef struct FB_GFXCTX { int id; int work_page; unsigned char **line; int max_h; int target_bpp; int target_pitch; void *las...

After several hours of trying, under Windows 8.1, I can't find any reasonable way to control the active code page, where reasonable means without modifying the registry, and the default (1252) does not include the original characters > 127. And setting the typeface to "fixedsys", "luc...

#include "windows.bi" dim ki(0 to 1) as INPUT_ if GetKeyState(VK_NUMLOCK) = 0 then ki(0).type = INPUT_KEYBOARD ki(0).ki.wVk = VK_NUMLOCK ki(0).ki.dwFlags = 0 ki(1).type = INPUT_KEYBOARD ki(1).ki.wVk = VK_NUMLOCK ki(1).ki.dwFlags = KEYEVENTF_KEYUP SendInput( 2, @ki(0), sizeof(ki) ) end if ...

You should expect problems compiling a source file anywhere in Program Files or Program Files (x86) because the directories are write protected. Your source files should be in a directory where you have write permission, normally an appropriate subdirectory of Users.

fxm wrote:Same result with the FB keyword CINT
...
In fact the rounding depends on program context!

Yes, that is the result I get, but why would the result vary with the context?

I would have guessed that CINT uses the CRT, but apparently not. #include "crt.bi" dim as single a1(0 to 20) = {-3.0,-2.7,-2.4,-2.1,-1.8,-1.5,-1.2,-0.9,-0.6, _ -0.3, 0.0,+0.3,+0.6,+0.9,+1.2,+1.5,+1.8,+2.1, _ +2.4,+2.7,+3.0 } dim as double a2(0 to 20) = {-3.0,-2.7,-2.4,-2.1,-1.8,-1.5,-1.2,-...

Although I cannot find the article ATM, from what I recall of it, for x86-64 code on Windows the X64 calling convention specified in the ABI is the only one used, and cdecl, etc are ignored. To test this I used the test code here , and specified the cdecl calling convention for the test function: .....

albert wrote: The outputs of both methods are just about the same numbers of digits.

Which indicates that both methods return sequences that are more or less uniformly distributed, but consider that it's possible to create non-random sequences that have a perfect uniform distribution.