The GetProcAddress uses the ANSI version of the API so the proper type for the
string is LPSTR, as found here:
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfinalpathnamebyhandlea
---
lib/stat-w32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
LoadLibrary is forbidden in such apps (can only load DLLs from within the app
package).
The API entries are available to all apps linking with the Windows API as found
here:
https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis
windowsapp.lib (and mincore.lib for Windows 8) are both
LoadLibrary is forbidden in such apps (can only load DLLs from within the app
package).
The API entries are available to all apps linking with the Windows API as found
here:
https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis
windowsapp.lib (and mincore.lib for Windows 8) are both
It may be outdated code, the value is never 2.
sys_types_h.m4 sets it to 0 or via gl_WINDOWS_STAT_INODES.
gl_WINDOWS_STAT_INODES sets it to 1 if compiled via mingw* and 0 otherwise.
---
lib/stat-w32.c | 107 +++--
lib/stat.c | 9
GetFileInformationByHandle() cannot be called. But the same information can be
gathered via calls to GetFileInformationByHandleEx() which is allowed.
A function pointer is used to pick between the local version using
GetFileInformationByHandleEx() and the system one.
If WINSTORECOMPAT is defined
ent in Windows 8 but removed in Windows 10.
Suggested by Steve Lhomme in
<https://lists.gnu.org/archive/html/bug-gnulib/2020-05/msg00318.html>.
* lib/ftruncate.c (_WIN32_WINNT): Don't set to a smaller value.
* lib/sethostname.c (_WIN32_WINNT): Likewise.
* lib/st
Any update on this ?
Just as in gettimeofday, one cannot use LoadLibrary to load system DLLs
in UWP builds. But they are available by static linking with windowsapp
and are guaranteed to be there.
On 2020-05-19 8:26, Steve Lhomme wrote:
LoadLibrary is forbidden in such apps (can only load
/blob/master/lib/Driver/ToolChains/MinGW.cpp#L269
On 2020-05-19 8:24, Steve Lhomme wrote:
LoadLibrary is forbidden in such apps (can only load DLLs from within the app
package).
The API entries are available to all apps linking with the Windows API as found
here:
https://docs.microsoft.com/en-us
On 2020-05-29 2:04, Bruno Haible wrote:
Hi,
Steve Lhomme wrote:
LoadLibrary is forbidden in such apps (can only load DLLs from within the app
package).
The API entries are available to all apps linking with the Windows API as found
here:
https://docs.microsoft.com/en-us/uwp/win32-and-com/win32
I think that's the other way around.
_UNICODE is meant to be used with tchar.h. I found 41 instances in a recent SDK.
UNICODE is the more generic term to chose between ANSI or WIDE API calls (if
you don't force them directly). I found 4123 instances in the same SDK.
So IMO the proper way is to
Why not use the proper call in the first place rather than use a define ?
It could be useful in a generic header used by all to make sure everyone uses
the right thing. But since you need to edit each file it would be cleaner not
to use any define at all and use the proper functions and
> On May 30, 2020 11:41 AM Bruno Haible wrote:
>
>
> Hi,
>
> Steve Lhomme wrote:
> > GetFileInformationByHandle() cannot be called. But the same information can
> > be
> > gathered via calls to GetFileInformationByHandleEx() which is allowed.
>
>
> On May 30, 2020 4:35 PM Bruno Haible wrote:
>
>
> Steve Lhomme wrote:
> > > So, it makes sense to put your code into a separate library, that
> > > implements
> > > Windows API on top of UWP API. Gnulib focuses (partially) on providing the
> > &g
> On May 30, 2020 4:31 PM Bruno Haible wrote:
>
>
> Steve Lhomme wrote:
> > Why not use the proper call in the first place rather than use a define ?
> > It could be useful in a generic header used by all to make sure everyone
> > uses the right thing. But si
> On May 30, 2020 5:47 PM Bruno Haible wrote:
>
>
> Steve Lhomme wrote:
> > > > You can see one of the last commit is adding
> > > > GetFileInformationByHandle() for example. But that means anyone
> > > > building with an older version of wi
---
lib/ftruncate.c | 2 ++
lib/sethostname.c | 6 --
lib/stat-w32.c| 6 --
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/lib/ftruncate.c b/lib/ftruncate.c
index a1856374e..990b71dbb 100644
--- a/lib/ftruncate.c
+++ b/lib/ftruncate.c
@@ -30,8 +30,10 @@
Hi,
On 2020-05-26 22:38, Bruno Haible wrote:
Hi Steve,
/* Ensure that declares GetFileSizeEx. */
+#if !defined(_WIN32_WINNT) || _WIN32_WINNT < 0x0500
# undef _WIN32_WINNT
# define _WIN32_WINNT _WIN32_WINNT_WIN2K
+#endif
What do you gain by this? What does it bring to compile
CreateFileA and CreateFileW are forbidden calls in UWP.
CreateFile2 is close enough, some parameters are passed in a structure
and it requires a WCHAR filename. Given the original stat uses the
"multibyte code page currently in use" [1], the char should be converted
using CP_ACP [2].
[1]
The API is forbidden [1] and HANDLE_FLAG_INHERIT would never be set as exec()
is not allowed either [2].
[1]
https://docs.microsoft.com/en-us/windows/win32/api/handleapi/nf-handleapi-gethandleinformation
[2]
Hi,
On 2023-05-16 16:52, Bruno Haible wrote:
Steve Lhomme wrote:
CreateFileA and CreateFileW are forbidden calls in UWP.
CreateFile2 is close enough, some parameters are passed in a structure
and it requires a WCHAR filename.
CreateFileW has an emulation in mingw's winstorecompat:
https
:
https://github.com/mirror/mingw-w64/blob/master/mingw-w64-libraries/winstorecompat/src/GetFileInformationByHandle.c
Steve Lhomme wrote:
The API is forbidden [1] and HANDLE_FLAG_INHERIT would never be set as exec()
is not allowed either [2].
[1]
https://docs.microsoft.com/en-us/windows/win32/api
21 matches
Mail list logo
