Pure FB Runtime Library (in progress)

[coderJeff]

Cool. Glad could help some. This is completely out-of-band, but if I don't ask I won't know; why quote entire posts? I notice there are a few members that use this practice.

[Munair]

Good point.

[Imortis]

... why quote entire posts?...

For me: laziness. I just didn't want to take the time to pick out the part I actually wanted. If you click the quote button on the post it copies the whole thing by default. I don't usually leave it but here lately I have been a bit rushed and didn't want to bother. I will make sure to do so from now on. It does look a bit cleaner, and only takes a few extra seconds.

EDIT: By the way, found the same problem with fseeko64. It is just a declaration, not an inline function, so I just included the declare. for it. Compiles fine.

[grindstone]

I'm afraid I'm a bit too late, but in spite of that, this is a list of files within the fbc installation (1.05 / windows / 32bit) containing ftello64:

• ...\lib\win32\libfb.a
  ...\lib\win32\libfbmt.a
  ...\lib\win32\libmingwex.a
  ...\lib\win32\libstdc++.a
  ...\lib\win32\libz.a

[jj2007]

Another way to get it in Windows:

Code: Select all

#include "windows.bi"
Dim as WIN32_FILE_ATTRIBUTE_DATA fInfo
GetFileAttributesEx("C:\pagefile.sys", GetFileExInfoStandard, @fInfo)
print "Size=";fInfo.nFileSizeLow+fInfo.nFileSizeHigh*2^32
Sleep

[MrSwiss]

@jj2007,

simpler than your calculations is: HIGHVAL SHL 32 + LOWVAL, as below:

Code: Select all

#include "windows.bi"

Dim As WIN32_FILE_ATTRIBUTE_DATA fInfo  ' file-size struct: contains 2 x DWord (ULong)
Dim As String fName = "c:\dev-tools\depends22\depends.exe"  ' select your file here

GetFileAttributesEx(fName, GetFileExInfoStandard, @finfo)
print "Size = "; Str(fInfo.nFileSizeHigh Shl 32 + fInfo.nFileSizeLow)

Sleep

BTW: "C:\pagefile.sys" won't work, on WIN10 ... (probably a security issue).
(For FBC 32, you'll probably need a cast to ULongInt ... is OK on FBC 64.)

[Imortis]

I'm afraid I'm a bit too late, but in spite of that, this is a list of files within the fbc installation (1.05 / windows / 32bit) containing ftello64:

• ...\lib\win32\libfb.a
  ...\lib\win32\libfbmt.a
  ...\lib\win32\libmingwex.a
  ...\lib\win32\libstdc++.a
  ...\lib\win32\libz.a

The only one that is important to me currently is the first two. Those are the RTLib and the Multi-Thread RTLib. I have found it all over the place in the dev_file_* source files. It's not a big issue any more, as I have a ready solution for now.

[marcov]

EDIT: By the way, found the same problem with fseeko64. It is just a declaration, not an inline function, so I just included the declare. for it. Compiles fine.

IIRC ftruncate and mmap are other similar cases (with 64-bit pararms also on 32-bit systems). But you might not use mmap (we use it for our malloc internals)

[jj2007]

simpler than your calculations is: HIGHVAL SHL 32 + LOWVAL, as below

Right, thanks. You can use or instead of +, too. The difficult part is to find a fat file for testing, see Get size of a file over 4 GB ;-)

[MrSwiss]

You can use or instead of +, too.

Or(ing) only makes sense for BitFields, aka: not useful in the given context.

[jj2007]

Or(ing) only makes sense for BitFields, aka: not useful in the given context.

If you SHL the hi dword into its natural destination, i.e. the upper part of a ULONGLONG, then the lower part is zero, and you can OR it with the 32 bits of the lo dword. Performance and code size are exactly the same. Btw FB-32 does apparently not recognise a LONGLONG, the results are identical but wrong (however, they are correct for files below 4GB):

Code: Select all

#include "windows.bi"

Dim As WIN32_FILE_ATTRIBUTE_DATA fInfo  ' file-size struct: contains 2 x DWord (ULong)
Dim As String fName = "GigaTest.txt"  ' select your file here

GetFileAttributesEx(fName, GetFileExInfoStandard, @finfo)
dim as LONGLONG qwPlus, qwOr
qwPlus=fInfo.nFileSizeHigh Shl 32 + fInfo.nFileSizeLow
qwOr=fInfo.nFileSizeHigh Shl 32 or fInfo.nFileSizeLow
print "Size = "; qwPlus
print "Size = "; qwOr
print "Size = "; Str(fInfo.nFileSizeHigh Shl 32 + fInfo.nFileSizeLow)
print "Size = "; Str(fInfo.nFileSizeHigh Shl 32 or fInfo.nFileSizeLow)
Sleep

Results for a 5,116,965,968 bytes file (get it here if you have a Masm32 installation):

Code: Select all

Size =  821998673
Size =  821998673
Size = 821998673
Size = 821998673

Same but compiled with FB64:

Code: Select all

Size =  5116965968
Size =  5116965968
Size = 5116965968
Size = 5116965968

Is the extra space for the "simple" prints by design?

[MrSwiss]

Btw FB-32 does apparently not recognise a LONGLONG, the results are identical but wrong

Well, that's exactly, why I've clearly written, that FBC 32 needs a Cast to ULongInt ...
(Integer = Long, in FBC 32; but LongInt, in FBC 64)

Code: Select all

print "Size = "; CULngInt(fInfo.nFileSizeHigh) Shl 32 + fInfo.nFileSizeLow

Is the extra space for the "simple" prints by design?

Yes, whenever you Print a signed Data-Type, a space is left (for negative values), which Str() removes.
(not so with: unsigned Data-Type's)

[Imortis]

I have another issue here. The con_print_raw.h and con_print_raw_wstr.h have the following two lines in them:

Code: Select all

#define FB_CONPRINTRAW fb_ConPrintRaw

Code: Select all

#define FB_CONPRINTRAW fb_ConPrintRawWstr

There is a function called "FB_CONPRINTRAW", but I don't understand why it is doing this, and I don't understand what needs to be done to make it compile correctly. If the full files in question are needed, I can post the code here, just let me know.

[coderJeff]

"FB_CONPRINTRAW" is a #define, and "fb_ConPrintRaw" is just it's value.
con_print_raw.c sets up some values in #defines and then #includes "con_print_raw_uni.h" where the are used (replaced).

Symbols are case sensitive in C, but in freebasic you have to carefully change one them to a different name. Do a case sensitive search across all the *.c|*.h files and replace FB_CONPRINTRAW with FB_CONPRINTRAW_PROCNAME or something similar.

The #defines in the .c file are like parameters to a big #macro in the .h file. I wouldn't make it a big macro though. You get better debugging info if you keep the same set-up with #defines and #include.

[Imortis]

I must have been too tired to see it clearly, because I had all the right pieces of info, I was just not putting them together. I came back and looked at it today and immediately worked it out.