I didn't make the change, so I am not sure what happened. (counting_pine notified me that something was up, which is how I got here now.)

I've changed my account password. Hopefully that will take care of the problem. If not, feel free to email me.

By the way...your pre-compiled version is a great idea, but fbrt0.o isn't included so it's not terribly useful... :( and the version that comes with the latest FB doesn't work with it. The runtime libraries (fbrt0.o included) should build out of the box from SVN on FreeBSD without problems. I don't...

I haven't tried it recently, but I wrote instructions some time ago for building on FreeBSD; the prebuilt binary linked at the top of the page should be enough to get you started. Judging by your error message, you might be using a Linux linker on FreeBSD; you need to use the native FreeBSD binutils...

Nearly everything in the Linux port is already generalized to use POSIX functions, where available, and work has been done in the direction of supporting other UNIX-like OSes. Have you tried it on your desired target? At the very least, minimal "hello world" (including fbgfx) works on Free...

I assume the problem is the VESA palette set (src/gfxlib2/dos/libfb_gfx_vesa_core.c - fb_dos_vesa_set_palette_int10); using FBGFX=vga makes it work correctly. The code in that area is a definite mess already; probably something simple overlooked...

Seems a bit excessive to me.. have you tried a straightforward implementation of the Euclidean algorithm ? I would bet the remainder would be faster than the repeated subtraction, especially for larger numbers. Function gcd2(u As Uinteger, v As Uinteger) As Uinteger do while v <> 0 var t = v v = u m...

After looking at this I wonder about making a "slip streamed" language dialect for fb which doesn't do the stuff like filling the buffer with nulls when it gets to EOF, all the locking checks (if they can be removed or are there strictly for the thread-safe rtl) but otherwise behaving exa...

The default fonts used by the graphics library are the standard VGA fonts indeed; they are stored in src/gfxlib2/data/*.fnt and compressed and included in the gfxlib when it is compiled.

I assume the rest is just how external routines are registered with Basic4GL (I've never used it); FB doesn't need anything like this.

The RunFile function could just be replaced by FB's built-in Shell.

Hey :) I just wondered something ... Couldn't I win some FPS by running subs in different threads ? eg : the different filling procedures in a thread A, Shaders processing in a thread B, and filtering in a thread C ? Can you do these tasks in parallel? If one task needs the output of another task a...

According to the MSDN page for ICOpen, you should link with vfw32, but apparently FB doesn't ship that library; try using the one from the MinGW w32api package.

The proper modern functions for this are getaddrinfo(), getnameinfo(), etc. There is a nice article about these functions here . The article title involves IPv6, but these functions are more generic than the old IPv4-only ones and work for (theoretically) any protocol (in practice, IPv4 and IPv6). H...

I only tested this on a Windows 2000 Terminal Services session (it previously crashed there), but it should hopefully work the same under safe mode or other environments without DX. Any other test results are welcome (and if it is a crash, it would be helpful if you could provide a backtrace).

You also must link with -lfb (or -lfbmt if you are using threads), and somewhere fb_Init should be called (called in main automatically in FB programs).