| Age | Commit message (Collapse) | Author |
|---|
|
#1840
kernel32.AddVectoredExceptionHandler -> ntdll.RtlAddVectoredExceptionHandler
kernel32.RemoveVectoredExceptionHandler -> ntdll.RtlRemoveVectoredExceptionHandler
kernel32.ExitProcess -> ntdll.RtlExitUserProcess
kernel32.InitializeCriticalSection -> ntdll.RtlInitializeCriticalSection
kernel32.EnterCriticalSection -> ntdll.RtlEnterCriticalSection
kernel32.LeaveCriticalSection -> ntdll.RtlLeaveCriticalSection
kernel32.DeleteCriticalSection -> ntdll.RtlDeleteCriticalSection
kernel32.TryAcquireSRWLockExclusive -> ntdll.RtlTryAcquireSRWLockExclusive
kernel32.AcquireSRWLockExclusive -> ntdll.RtlAcquireSRWLockExclusive
kernel32.ReleaseSRWLockExclusive -> ntdll.RtlReleaseSRWLockExclusive
kernel32.WakeConditionVariable -> ntdll.RtlWakeConditionVariable
kernel32.WakeAllConditionVariable -> ntdll.RtlWakeAllConditionVariable
kernel32.HeapReAlloc -> ntdll.RtlReAllocateHeap
kernel32.HeapAlloc -> ntdll.RtlAllocateHeap
|
|
missing alloction constants MEM_RESERVE_PLACEHOLDER / MEM_PRESERVE_PLACEHOLDER
|
|
|
|
|
|
This implementation is now a direct replacement for the `kernel32` one.
New bitflags for named pipes and other generic ones were added based on
browsing the ReactOS sources.
`UNICODE_STRING.Buffer` has also been changed to be nullable, as
this is what makes the implementation work.
This required some changes to places accesssing the buffer after a
`SUCCESS`ful return, most notably `QueryObjectName` which even referred
to it being nullable.
|
|
Update windows.zig
Update windows.zig
Update windows.zig
Update windows.zig
Update windows.zig
Update windows.zig
Update windows.zig
Update ntdll.zig
Update windows.zig
Update ntdll.zig
Update kernel32.zig
|
|
Co-authored-by: e4m2 <git@e4m2.com>
|
|
I had accidentally regressed support for -gdwarf in 461fb499f3cff9038a427eae120fb34defc9ab38 when I changed the logic to
use the already-mapped exe/dll image instead of loading it from disk. The string table is mapped as all zeroes by the loader,
so if a section header's name is longer than 8 bytes (like the ones generated by -gdwarf), then the name can't be read.
Now, if any section headers require the string table, the file is mapped from disk.
windows: Add NtCreateSection/NtMapViewOfSection/NtUnmapViewOfSection
|
|
namespaced/device paths""
This reverts commit b5fad3a40a86eb379903d6a803bdbe66dcaa5487.
The latent x86_64 backend bug has been fixed.
|
|
paths"
This reverts commit 1697d44809151e4759f6b5f9447a908c30ac1e84.
Master branch started failing after this commit landed.
|
|
There are many different types of Windows paths, and there are a few different possible namespaces on top of that. Before this commit, NT namespaced paths were somewhat supported, and for Win32 paths (those without a namespace prefix), only relative and drive absolute paths were supported. After this commit, all of the following are supported:
- Device namespaced paths (`\\.\`)
- Verbatim paths (`\\?\`)
- NT-namespaced paths (`\??\`)
- Relative paths (`foo`)
- Drive-absolute paths (`C:\foo`)
- Drive-relative paths (`C:foo`)
- Rooted paths (`\foo`)
- UNC absolute paths (`\\server\share\foo`)
- Root local device paths (`\\.` or `\\?` exactly)
Plus:
- Any of the path types and namespace types can be mixed and matched together as appropriate.
- All of the `std.os.windows.*ToPrefixedFileW` functions will accept any path type, prefixed or not, and do the appropriate thing to convert them to an NT-prefixed path if necessary.
This is achieved by making the `std.os.windows.*ToPrefixedFileW` functions behave like `ntdll.RtlDosPathNameToNtPathName_U`, but with a few differences:
- Does not allocate on the heap (this is why we can't use `ntdll.RtlDosPathNameToNtPathName_U` directly, it does internal heap allocation).
- Relative paths are kept as relative unless they contain too many .. components, in which case they are treated as 'drive relative' and resolved against the CWD (this is how it behaved before this commit as well).
- Special case device names like COM1, NUL, etc are not handled specially (TODO)
- `.` and space are not stripped from the end of relative paths (potential TODO)
Most of the non-trivial conversion of non-relative paths is done via `ntdll.RtlGetFullPathName_U`, which AFAIK is used internally by `ntdll.RtlDosPathNameToNtPathName_U`.
Some relevant reading on Windows paths:
- https://googleprojectzero.blogspot.com/2016/02/the-definitive-guide-on-win32-to-nt.html
- https://chrisdenton.github.io/omnipath/Overview.html
Closes #8205
Might close (untested) #12729
Note:
- This removes checking for illegal characters in `std.os.windows.sliceToPrefixedFileW`, since the previous solution (iterate the whole string and error if any illegal characters were found) was naive and won't work for all path types. This is further complicated by things like file streams (where `:` is used as a delimiter, e.g. `file.ext:stream_name:$DATA`) and things in the device namespace (where a path like `\\.\GLOBALROOT\??\UNC\localhost\C$\foo` is valid despite the `?`s in the path and is effectively equivalent to `C:\foo`). Truly validating paths is complicated and would need to be tailored to each path type. The illegal character checking being removed may open up users to more instances of hitting `OBJECT_NAME_INVALID => unreachable` when using `fs` APIs.
+ This is related to https://github.com/ziglang/zig/issues/15607
|
|
`GetPhysicallyInstalledSystemMemory` uses SMBios to grab the physical
memory size which can lead to unecessary allocation and inacurate
representation of the total memory. Using `System_Basic_Information`
help to retrieve the physical memory which is not reserved for the
kernel/tables. This aligns better with the linux side as `/proc/meminfo`
does the same thing.
|
|
|
|
|
|
|
|
|
|
`GetProcessMemoryInfo` is implemented using `NtQueryInformationProcess`
with `ProcessVmCounters` to obtain `VM_COUNTERS`. The structs, enum
definitions are found in `winternl.h` or `ntddk.h` in the latest WDK.
This should give the same results as using `K32GetProcessMemoryInfo`
|
|
- Fixes the first few code units of the name being omitted (it was using `@sizeOf(FILE_NAME_INFO)` as the start of the name bytes, but that includes the length of the dummy [1]u16 field and padding; instead the start should be the offset of the dummy [1]u16 field)
- Replaces kernel32.GetFileInformationByHandleEx call with ntdll.NtQueryInformationFile
+ Contributes towards #1840
- Checks that the handle is a named pipe first before querying and checking the name, which is a much faster call than NtQueryInformationFile (this was about a 10x speedup in my probably-not-so-good/take-it-with-a-grain-of-salt benchmarking)
|
|
|
|
a new implementation which uses RtlVirtualUnwind instead (#12740)
windows: add RtlCaptureContext, RtlLookupFunctionEntry, RtlVirtualUnwind and supporting types
windows: fix alignment of CONTEXT structs to match winnt.h as required by RtlCaptureContext (fxsave instr)
windows aarch64: fix __chkstk being defined twice if libc is not linked on msvc
Co-authored-by: Jakub Konka <kubkon@jakubkonka.com>
|
|
|
|
|
|
|
|
Co-authored-by: Veikka Tuominen <git@vexu.eu>
|
|
|
|
EnvMap provides the same API as the previously used BufMap (besides `putMove` and `getPtr`), so usage sites of `getEnvMap` can usually remain unchanged.
For non-Windows, EnvMap is a wrapper around BufMap. On Windows, it uses a new EnvMapWindows to handle some Windows-specific behavior:
- Lookups use Unicode-aware case insensitivity (but `get` cannot return an error because EnvMapWindows has an internal buffer to use for lookup conversions)
- Canonical names are returned when iterating the EnvMap
Fixes #10561, closes #4603
|
|
Windows does Unicode-aware case-insensitivity comparisons for environment variable names. Before, os.getenvW was only doing ASCII case-insensitivity. We can take advantage of RtlEqualUnicodeString in NtDll to get the proper Unicode case insensitivity.
|
|
|
|
I've seen having this be wrong break some cross-compilers, and it's
also how it is in other files so it's best to be consistent.
It's also just the actual casing of the file.
|
|
zig fmt now replaces c_void with anyopaque to make updating
code easy.
|
|
The proposal #9629 is now accepted, usingnamespace stays but no longer
puts identifiers in scope.
|
|
Down to 19 uses of `usingnamespace`.
|
|
We already have a LICENSE file that covers the Zig Standard Library. We
no longer need to remind everyone that the license is MIT in every single
file.
Previously this was introduced to clarify the situation for a fork of
Zig that made Zig's LICENSE file harder to find, and replaced it with
their own license that required annual payments to their company.
However that fork now appears to be dead. So there is no need to
reinforce the copyright notice in every single file.
|
|
This modifies the lock semantics from using AccessMode to using
NtLockFile/NtUnlockFile.
This is a breaking change.
|
|
|
|
* std.Thread.Futex: implementation + tests
* std.Thread.Futex: fix darwin compile errors
* std.Thread.Futex: fix wait() documentation typo
* std.Thread.Futex: fix darwin version check
* std.Thread.Futex: remove unnecessary comptime keyword
|
|
|
|
|
|
|
|
|
|
|
|
|
|
add SPDX license identifier
copyright ownership is zig contributors
|
|
This commit replaces `windows.DeviceIoControl` with
`windows.FsControlFile` which is a wrapper around the NT-based
syscall `ntdll.NtFsControlFile`.
|
|
|
|
Closes #4581
|
|
|
|
https://github.com/daurnimator/zig
|
|
|
|
|
