Re: error building Fox-1.7.90 on windows

When I try to compile one of my programs (64-bit v1.7.90) I got
this error:


FOX-1.7.lib(FXString.obj) : error LNK2038: mismatch detected for
'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value
'MT_StaticRelease' in ChangeWidgetColors.obj


In the project setting for building the foxlib I had to switch
the "Runtime Library" from type: dll to lib


In my programs:

In debug:

error C2039: 'unescape': is not a member of 'FX::FXString'

I had to change it to:

comparecase()
unescape()

now the debug buils and runs fine.


in release these work:

FXString::comparecase()
FXString:: unescape()


But I'm getting this error now:

1>FOX-1.7.lib(FXDir.obj) : error LNK2019: unresolved external
symbol WNetOpenEnumW referenced in function "public: static int
__cdecl FX::FXDir::listShares(class FX::FXString * &)"
(?listShares@FXDir@FX@@SAHAEAPEAVFXString@2@@Z)
1>FOX-1.7.lib(FXDir.obj) : error LNK2019: unresolved external
symbol WNetEnumResourceW referenced in function "public: static
int __cdecl FX::FXDir::listShares(class FX::FXString * &)"
(?listShares@FXDir@FX@@SAHAEAPEAVFXString@2@@Z)
1>FOX-1.7.lib(FXDir.obj) : error LNK2019: unresolved external
symbol WNetCloseEnum referenced in function "public: static int
__cdecl FX::FXDir::listShares(class FX::FXString * &)"
(?listShares@FXDir@FX@@SAHAEAPEAVFXString@2@@Z)
1>GetPlotData.exe : fatal error LNK1120: 3 unresolved externals









-----Original Message-----
From: [email protected] <[email protected]> 
Sent: Thursday, June 18, 2026 9:18 AM
To: [email protected]
Cc: [email protected]; [email protected]
Subject: Re: [Foxgui-users] error building Fox-1.7.90 on windows

On 2026-06-18 07:38, John Selverian wrote:
> That fixed it. Thanks.
> 
> 2 questions:
> 
> 1) I get a bunch of conversion warnings...are you interested in
seeing 
> these or do you already know about them?

Remember I cobbled together the Visual Studio project files to
begin with; I can compile it myself and see them.

The problem is, partially, you can still compile FOX as 32-bit as
well, and some warning fixes would be "unfixed" when you switch
built targets.
from x64-64 to x86.

On linux, also, I still occasionally test on 32-bit raspberry pi,
although the move to 64 bit arm is in advanced stage.  The
situation is a bit better as I do not pass -Wconversion flag
there [it flags too much].

I do occasionally have -Wconversion flag on, to see if it catches
anything worthwhile; widening 32- to 64-bit is hardly ever a
problem.  The other way around *could* be, some times.

In the integer world, conversions don't really cost anything;
loading small value and widening is one instruction on x64-cpu.

In the floating point world, there is pain doing conversions.
Its not a lot of pain for scalars, but for vector programming one
could leave a 2x performance loss, since vector registers hold
half as many doubles as singles.

GCC has a separate flag for that, and its always on.  For more
performance-
sensitive programs, I occasionally chase down all places where
this flag reports problems.


> 2) The library is called "foxlib.lib" the current one I'm using
> is called "FOX-1.7.lib" Did you or I change the name?

Not consciously...


> 1 observation, it's probably a c++ question:
> 
> I have a very large data structure. When the program is running
> it uses about 700 MB of RAM. It runs without problems. I also
> have a mode where it makes some copies of this large data
> structure and runs a bunch of checks on it. When it is doing
this
> is used about 2.4 GB. I recently noticed that the data
structure
> is now being corrupted when I run these checks. After much
> debugging I decided to change my app from 32-bit to 64-bit. It
> now runs fine.

Yes, in 32-bit mode, you can not use more than 4GB.  Actually,
its
less, as libraries, o.s. etc. also take up some space.

I believe the real limit is 3GB, at least on linux it is.  It may
be
less on Windows.

Some processors had page table tricks to allow aggregate
collection of
processes to use more than 4GB physical ram. but all that is moot
in
the 64-bit world.

Most 64-bit CPUs have limit to 48 bits, but some are pushing to a
few
more bits 50 maybe 52.  However 48 seems common.

With current RAM prices, you can't afford that much memory anyway
;-)

2^48 =        281,474,976,710,656              281TB
2^52 =      4,503,599,627,370,496             4500TB or 4.5PB
2^64 = 18,446,744,073,709,551,616         18446744TB or 18.4EB

Around ~1TB is doable on high-end server hardware. But blurring
the lines between RAM and SSD, I can see going beyond 2^48 if
you wanted to memory-map large SSD storage into virtual memory.




    -- JVZ