found it: `tools/build_defs/oss/osquery/cxx.bzl`. ...
# windows
y
found it:
tools/build_defs/oss/osquery/cxx.bzl
. does anybody know why we’re capping features at Windows 7?
a
The set of used features in osquery from windows api is fit to version range win7...win10. Thereby the minimal supported version of windows is 7.
y
that makes sense, but couldn’t that be imposed by checking for
>= _WIN32_WINNT_WIN7
instead? it’s currently impossible to use any non-Windows 7 features thanks to the hard define
a
Correct me please if Im wrong.
_WIN32_WINNT
is a minimal version of win32 api, but not the version of os itself. So, I is not gonna be an obstacle to use features from the versions before win32 v7, because of backward compatibility. Except that features was deprecated in win7.
About the features from the versions newer win7. We could not use them in osquery for now, otherwise it will break win7 compatibility.
But, if you depend on osquery headers somewhere and want to use win10 features you could redefine that macro after include of osquery header. I know the solution looks awful, but it is what it is because of win32 api =\
y
yep, i think you’re right about that. i probably didn’t express myself well: i think that osquery should check for
_WIN32_WINNT >= _WIN32_WINNT_WIN7
and then do two builds on the CI: one for
_WIN32_WINNT_WIN7
and one for the system default. that would allow individual tables to do feature testing without redefining the macro (which would be ugly, like you said), but would still preserve Win 7 compatibility since it would make any non-guarded features a build failure
at least in my case, redefining won’t be good — i’m trying to use NTFS structures that were added in Windows 8 when possible, but with a graceful fallback to Windows 7. redefining
_WIN32_WINNT
to something higher will expose those structures, but will probably make it impossible to merge my changes (since they won’t be windows 7 compatible)
a
May it would be a bit better to discuss you case with the code. You are trying to use some features from v8 api in the new table and use build it for win8 and newer versions of windows, right? Do you have some draft of your changes (like branch in you repo), may I have a look?
and yeah, i’m trying to use some new features (specifically the
FILE_ID_128
structure and
GetFileInformationByHandleEx
function) for a new table
a
awesome, lemme have look tomorrow and I'll get back to you
👍 1
y
FYI, i was able to approximate the features that i wanted in the Windows 8+ APIs without breaking compatibility. i’d still like to propose that osquery make it easier to use the new APIs, but please feel free to ignore that branch now 🙂
a
Sorry for the delay. That solution works for normal win7 compatible build. https://github.com/facebook/osquery/pull/5346 Is it ok for your branch?
y
yeah, this is perfect, thanks!
a
Cool, thank you 🙂