<headius>
this windows symlink thing is broken after my PR, my bad for not actually testing it
<headius>
but I assumed it worked and it doesn't appear to
<headius>
it requires 'ffi' and then checks if `::FFI::Config` is defined to know it loaded correctly
<headius>
as far as I can tell there is no FFI::Config
<headius>
I have it working now checking instead for FFI::Platform but I will look into why it used Config
<headius>
this code was borrowed from a djberg win32 library
<enebo[m]>
headius: yeah based on last comment from the issue on this the original fix never worked either so I guess maybe that could be part of the reason?
<enebo[m]>
Or something changed in last few years and we didn't notice
<headius>
well I have it back to not working like it did at some point but it just raises EACCES
<headius>
and djberg96 on GH no longer has this repo
<headius>
I got permission from djberg to include it in JRuby at whatever point we attempted to fix this
<headius>
this code does not do the FFI::Config check so I think maybe we just borked that
<headius>
probably to let it start up without FFI present
<headius>
do you know what permissions are needed to be able to do symlinks on Windows?
<enebo[m]>
oh
<enebo[m]>
it used to be admin but who knows if it is still true
<enebo[m]>
I think on windows they are called channels?
<enebo[m]>
err junctions
<enebo[m]>
"On Windows 10’s Creators Update, you can use a normal Command Prompt window, without running it as an Administrator. However, to do this without an Administrator Command Prompt window, you must first enable Developer Mode from Settings > Update & Security > For Developers."
<enebo[m]>
So weird setting OR run as admin
<headius>
why did CRuby bother with this
<enebo[m]>
Windows 15 will allow normal users to do it :)
<headius>
whatevs
<enebo[m]>
Windows 11 is coming out but is there a reason to move to it
<enebo[m]>
"Price: Free upgrade for existing Windows 10 users"
<enebo[m]>
lol so I wonder how much MS strategy on monetizing windows changed
<headius>
I haven't understood why they charge for unsupported use at all
<headius>
so the FFI check is not sufficient because parts will load even if native is turned off I guess?
<enebo[m]>
ah ok. makes sense that it was not just FFI before then
<headius>
I'm just going to modify this code to do the whole FFI setup in the begin/rescue and if anything fails just define it to raise NotImplemented
<enebo[m]>
makes me wish Ruby had transactional loads
<headius>
and not check for FFI constants or whatever
<headius>
I already started doing this in the PR because it checks for FFI and then checks for the proper win32 function
<headius>
and both paths just silently fail
<enebo[m]>
FFI can fail to load on any esoteric OS where no one has tried to run it. I guess as a cext they assume if it compiles it will work but that clearly is not true
<headius>
yeah they don't have the sort of platform options we do either
<headius>
like disabling all native calls
<enebo[m]>
I half wonder if adding a FFI::loaded? would be a reasonable feature but I guess then there would need to be a sensible test
<enebo[m]>
What thing in FFI is a reasonable test that it loaded?
<enebo[m]>
from a black block perspective we could only try and use it but that is way too expensive
<headius>
it might be a reasonable thing to add to FFI proper
<headius>
and then we would just inherit it
<headius>
I have no idea if there are cases in CRuby FFI that might partially load
<enebo[m]>
FFI::Version is the last file required in ffi/ffi
<enebo[m]>
but we probably load and then don't work
<headius>
yeah I am not sure what we can use in there so I think this is best... do the entire load + define logic in the begin and if either thing fails fall back on NotImpl
<headius>
I am fixing the Solaris logic below also, and will split these into separate files for readability