Rust bindings to Windows API

Overview

winapi-rs

Build status Build status Build Status Gitter Crates.io Lines of Code 100% unsafe Open issues License

Documentation

Official communication channel: #windows-dev on the Rust Community Discord

This crate provides raw FFI bindings to all of Windows API. They are gathered by hand using the Windows 10 SDK from Microsoft. I aim to replace all existing Windows FFI in other crates with this crate through the "Embrace, extend, and extinguish" technique.

If this crate is missing something you need, feel free to create an issue, open a pull request, or contact me via other means.

This crate depends on Rust 1.6 or newer on Windows. On other platforms this crate is a no-op and should compile with Rust 1.2 or newer.

Frequently asked questions

How do I create an instance of a union?

Use std::mem::zeroed() to create an instance of the union, and then assign the value you want using one of the variant methods.

Why am I getting errors about unresolved imports?

Each module is gated on a feature flag, so you must enable the appropriate feature to gain access to those items. For example, if you want to use something from winapi::um::winuser you must enable the winuser feature.

How do I know which module an item is defined in?

You can use the search functionality in the documentation to find where items are defined.

Why is there no documentation on how to use anything?

This crate is nothing more than raw bindings to Windows API. If you wish to know how to use the various functionality in Windows API, you can look up the various items on MSDN which is full of detailed documentation.

Can I use this library in no_std projects?

Yes, absolutely! By default the std feature of winapi is disabled, allowing you to write Windows applications using nothing but core and winapi.

Why is winapi's HANDLE incompatible with std's HANDLE?

Because winapi does not depend on std by default, it has to define c_void itself instead of using std::os::raw::c_void. However, if you enable the std feature of winapi then it will re-export c_void from std and cause winapi's HANDLE to be the same type as std's HANDLE.

Should I still use those -sys crates such as kernel32-sys?

No. Those crates are a legacy of how winapi 0.2 was organized. Starting with winapi 0.3 all definitions are directly in winapi itself, and so there is no longer any need to use those -sys crates.

Example

Cargo.toml:

[target.'cfg(windows)'.dependencies]
winapi = { version = "0.3", features = ["winuser"] }

main.rs:

#[cfg(windows)] extern crate winapi;
use std::io::Error;

#[cfg(windows)]
fn print_message(msg: &str) -> Result<i32, Error> {
    use std::ffi::OsStr;
    use std::iter::once;
    use std::os::windows::ffi::OsStrExt;
    use std::ptr::null_mut;
    use winapi::um::winuser::{MB_OK, MessageBoxW};
    let wide: Vec<u16> = OsStr::new(msg).encode_wide().chain(once(0)).collect();
    let ret = unsafe {
        MessageBoxW(null_mut(), wide.as_ptr(), wide.as_ptr(), MB_OK)
    };
    if ret == 0 { Err(Error::last_os_error()) }
    else { Ok(ret) }
}
#[cfg(not(windows))]
fn print_message(msg: &str) -> Result<(), Error> {
    println!("{}", msg);
    Ok(())
}
fn main() {
    print_message("Hello, world!").unwrap();
}

Financial Support

Do you use winapi in your projects? If so, you may be interested in financially supporting me on Patreon. Companies in particular are especially encouraged to donate (I'm looking at you Microsoft).

Comments
  • Update license and copyright header

    Update license and copyright header

    I would like to update winapi to be dual licensed under MIT and Apache 2.0. For the sake of consistency I would also like to update the copyright header in every file as follows.

    // Copyright © 2016 winapi-rs developers
    // Licensed under the Apache License, Version 2.0
    // <LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
    // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your option.
    // All files in the project carrying such notice may not be copied, modified, or distributed
    // except according to those terms.
    

    To do this I need the consent of contributors to this project so please state whether you consent here. Even if you don't consent, I still need to know so I can rewrite your contribution from scratch. Thanks.

    • [x] @aarzee
    • [x] @Aceeri
    • [x] @alexcrichton
    • [x] @application-developer-DA
    • [x] @ArtemGr
    • [x] @bitbegin
    • [x] @Boddlnagg
    • [x] @bozaro
    • [x] @bungcip
    • [ ] @bvinc
    • [ ] @bvinc83
    • [x] @cessationoftime
    • [x] @cmr
    • [x] @Connorcpu
    • [x] @cpardotortosa
    • [ ] @CrimsonVoid
    • [x] @CruzBishop
    • [x] @Daggerbot
    • [x] @danburkert
    • [x] @DanielKeep
    • [x] @diaphore
    • [x] @Diggsey
    • [x] @DoumanAsh
    • [x] @Draivin
    • [x] @Eh2406
    • [x] @excaliburHisSheath
    • [x] @ForNeVeR
    • [x] @gentoo90
    • [x] @Havvy
    • [x] @iliekturtles
    • [x] @inrustwetrust
    • [x] @Jascha-N
    • [x] @jeandudey
    • [x] @jmesmon
    • [x] @jminer
    • [ ] @jojonv
    • [x] @Jonesey13
    • [x] @ktrance
    • [x] @mmitteregger
    • [x] @msiglreith
    • [x] @Osspial
    • [x] @overdrivenpotato
    • [x] @pdib
    • [x] @recombinant
    • [x] @red75prime
    • [x] @retep998
    • [x] @rpjohnst
    • [x] @seanmonstar
    • [x] @sectopod
    • [x] @sfackler
    • [x] @skdltmxn
    • [x] @skeleten
    • [x] @Stebalien
    • [x] @steffengy
    • [x] @thelink2012
    • [x] @tomaka
    • [ ] @toolness
    • [x] @varding
    • [x] @Xirdus
    • [x] @yonran
    opened by retep998 62
  • Finish porting advapi32 to v0.3

    Finish porting advapi32 to v0.3

    Used @Susurrus's fork as a base.

    All functions exported by advapi32 that can be found in the SDK headers* have been added to their corresponding Rust files with the exception of SetServiceBits (um/LMServer.h). If a Rust version of a header already existed then only the required pieces were added to the file. If the Rust file didn't exist already the full header was ported to the extent I was able to.

    *139 functions are exported from the DLL but have no declaration in any header in the latest Windows SDK.

    opened by austinwagner 33
  • Porting more APIs to 0.3

    Porting more APIs to 0.3

    This is blocking on #437, which is why that commit shows up here as well. I've realized merging can be problematic when pulling stuff out of these large older source files, so I've been stacking them up. Maybe I'll submit a bunch as a single PR in the future so the inter-patch dependencies are less of an issue.

    I'm filing this now to get a head-start on any compilation builds on CI.

    opened by Susurrus 24
  • winapi 0.3 overhaul

    winapi 0.3 overhaul

    All progress is in the dev branch.

    • [x] Remove all trait impls except Copy and Clone.
      • [x] Update all macros to do so.
      • [x] Get rid of any derives that are floating around, not behind a macro.
    • [x] Make enums nothing more than integer constants with the enum type being an alias for u32.
    • [x] Update all copyrights and license stuff. https://github.com/retep998/winapi-rs/issues/308
    • [x] For each header do the following:
      • Move it to the appropriate directory based on where it is located in the Windows SDK such as um or shared.
      • Create a feature for that header such as foo.
      • Add the appropriate pub mod foo; to that folder's module.
      • Add a cfg to that mod such as #[cfg(feature = "foo")].
      • Get rid of all :: and add imports to pull in any definitions it needs from other headers.
      • Add the feature to build.rs and specify its dependencies on other headers and also libraries.
    • [x] For each -sys crate do the following:
      • Move the function definitions to the header module where it is actually defined.
      • Ensure that any header that has functions from that library specifies that dependency in build.rs.
    • [x] Update all usage of UNION! to UNION2!. Once that is done, rename UNION2! to UNION!.
    • [x] Inform everyone with an open PR that they'll need to update their PR for the new world order.
    opened by retep998 24
  • Add iphlpapi support

    Add iphlpapi support

    Issue: https://github.com/retep998/winapi-rs/issues/561

    Files:

    C Header | Rust | Review ----------------- | --------------------------------------- | -------- shared/ifdef.h | shared/ifdef.rs | TODO shared/ifmib.h | shared/ifmib.rs | TODO shared/ipifcons.h | shared/ipifcons.rs | TODO shared/ipmib.h | shared/ipmib.rs | TODO shared/Iprtrmib.h | shared/iprtrmib.rs | TODO shared/mprapidef.h | shared/mprapidef.rs | TODO shared/nldef.h | shared/nldef.rs | TODO shared/tcpestats.h | shared/tcpestats.rs | TODO shared/tcpmib.h | shared/tcpmib.rs | TODO shared/udpmib.h | shared/udpmib.rs | TODO um/IPExport.h | um/ipexport.rs | TODO um/IPTypes.h | um/iptypes.rs | TODO um/iphlpapi.h | um/iphlpapi.rs | TODO

    Stage:

    • [ ] Dependency Tree ( build.rs )
    • [ ] Header Translation
    • [ ] Code Style
    opened by LuoZijun 18
  • Update ::sapi and move to um::sapi

    Update ::sapi and move to um::sapi

    Work in progress. I still need to clear up a few things in um::sapi and add um::sapiaut + um::sapiddk. This PR also brings in um::servprov and an incomplete um::urlmon. I can either finish the latter in this PR or in a separate one later.

    opened by docbrown 16
  • EnumWindows‘s callback's LPARAM should be a reference.

    EnumWindows‘s callback's LPARAM should be a reference.

    C code:

    BOOL CALLBACK EnumWindowsProc(HWND hwnd, LPARAM lParam)
    {
        char buffer[128];
        int written = GetWindowTextA(hwnd, buffer, 128);
        if (written && strstr(buffer,"Mozilla Firefox") != NULL) {
            *(HWND*)lParam = hwnd;
            return FALSE;
        }
        return TRUE;
    }
    
    HWND GetFirefoxHwnd()
    {
        HWND hWnd = NULL;
        EnumWindows(EnumWindowsProc, &hWnd);
        return hWnd;
    }
    

    So we can get the hwnd from lParam.

    But in Rust version, we can't get it out of enum_windows_proc function.

    opened by AurevoirXavier 11
  • add support for aarch64-pc-windows-msvc

    add support for aarch64-pc-windows-msvc

    A lot of this is just finding places where we were conditionalizing on target_arch = "x86_64" and using a target_pointer_width test instead. The real interesting parts are in winnt.rs.

    I'm not sure of a good way to test this. Everything builds OK on x86_64-pc-windows-msvc, so I haven't broken anything. Unfortunately, the aarch64-pc-windows-msvc target is in a bit of a rough state (see rust-lang/rust#53864), and I can't build libstd for that target locally. I did try making the aarch64 definitions compile on x86_64 (and vice versa) in winnt.rs, and building with that change seemed to be OK.

    opened by froydnj 11
  • Add Support for Iphlpapi Libraries, Second Attempt

    Add Support for Iphlpapi Libraries, Second Attempt

    This is still a WIP. I picked up where @LuoZijun left off. I now have all tests passing with no build warnings. I still need to do some code cleanup and confirm that all constants, definitions, and functions have been flushed out.

    This is my first ever pull request. My apologies for rookie mistakes, I appreciated any and all commentary/criticism.

    Matt

    opened by mattlknight 11
  • Added many bindings for runtimeobject

    Added many bindings for runtimeobject

    As the title says. This is required for working with the Windows Runtime.

    Note that there's currently a bug in the bundled runtimeobject.a, so the linker can't link to RoUninitialize on the i686-pc-windows-gnu toolchain.

    Update: This is now a strict superset of #279

    opened by Boddlnagg 11
  • Add ConPty APIs

    Add ConPty APIs

    Closes #695.

    I added the bare minimum to cover those three functions. These APIs will only work on the very newest Windows. Does anything need to be done to feature gate them?

    opened by davidhewitt 10
  • Error when calling winapi::um::fileapi::CreateFileW()

    Error when calling winapi::um::fileapi::CreateFileW()

    I'm trying to make a backup program for my MBR. To accomplish this task, I use CreateFileW, but when I try to use this function with the parameters in the documentation (https://docs.rs/winapi/latest/winapi/um/fileapi/fn.CreateFileW.html), I get the following error: 2022-11-27_12-04

    My code is: `#[cfg(windows)] extern crate winapi; use winapi::shared::minwindef::DWORD; use winapi::um::fileapi::{CreateFileW, OPEN_EXISTING}; use winapi::um::winnt::{FILE_SHARE_READ, GENERIC_ALL, HANDLE, LPCWSTR};

    fn main() { let mut drive: HANDLE = CreateFileW( "\\.\PhysicalDrive0" as LPCWSTR, GENERIC_ALL, FILE_SHARE_READ, 0 as DWORD, OPEN_EXISTING, 0 as DWORD, 0 as DWORD, ); }`

    opened by someordinaryidiot 0
  • add/refactor missing process mitigation policy definitions

    add/refactor missing process mitigation policy definitions

    PROCESS_MITIGATION_POLICY Enum

    • [x] ⚡Added ProcessSystemCallFilterPolicy[^1] definition
    • [x] ⚡Added ProcessPayloadRestrictionPolicy[^1] definition
    • [x] ⚡Added ProcessChildProcessPolicy[^1] definition
    • [x] ⚡Added ProcessSideChannelIsolationPolicy[^1] definition
    • [x] ⚡Added ProcessUserShadowStackPolicy[^1] definition
    • [x] ⚡Added ProcessRedirectionTrustPolicy[^1] definition
    • [x] ⚡Added ProcessUserPointerAuthPolicy[^1] definition
    • [x] ⚡Added ProcessSEHOPPolicy[^1] definition

    Structs

    • [x] ⚡Added PROCESS_MITIGATION_SEHOP_POLICY[^1] definition
    • [x] 👆Updated PROCESS_MITIGATION_SYSTEM_CALL_DISABLE_POLICY[^1] definition
    • [x] 👆Updated PROCESS_MITIGATION_DYNAMIC_CODE_POLICY[^1] definition
    • [x] 👆Updated PROCESS_MITIGATION_CONTROL_FLOW_GUARD_POLICY[^1] definition
    • [x] 👆Updated PROCESS_MITIGATION_BINARY_SIGNATURE_POLICY[^1] definition
    • [x] 👆Updated PROCESS_MITIGATION_IMAGE_LOAD_POLICY[^1] definition
    • [x] ⚡Added PROCESS_MITIGATION_USER_SHADOW_STACK_POLICY[^1] definition
    • [x] ⚡Added PROCESS_MITIGATION_SIDE_CHANNEL_ISOLATION_POLICY[^1] definition
    • [x] ⚡Added PROCESS_MITIGATION_USER_POINTER_AUTH_POLICY[^1] definition
    • [x] ⚡Added PROCESS_MITIGATION_REDIRECTION_TRUST_POLICY[^1] definition

    [^1]: As of Windows SDK 10.0.22621.0 winnt.h

    opened by kkent030315 0
  • Cannot initialize NOTIFYICONDATAA_u

    Cannot initialize NOTIFYICONDATAA_u

    The struct NOTIFYICONDATAW / NOTIFYICONDATAA is used to create icons on the System Tray.

    One of it's fields is a union of type NOTIFYICONDATAA_u.

    AFAIK, there's no way to create such union, since it's fields are private. Therefore I don't believe we can create icons on the System Tray.

    I suspect it is necessary to make one of the union's fields public in order to create it.

    opened by rrebelo62 0
  • v0.2 branch: derive Copy instead of implementing it by hand

    v0.2 branch: derive Copy instead of implementing it by hand

    Fixes https://github.com/retep998/winapi-rs/issues/1030

    Turns out hyper 0.12 transitively depends via tokio 0.1 on winapi 0.2. Would be good to get a semver-compatible update out so that these crates can be kept working.

    opened by RalfJung 0
  • Heads-up: winapi 0.2.8 will fail to build soon-ish

    Heads-up: winapi 0.2.8 will fail to build soon-ish

    In https://github.com/rust-lang/rust/pull/102513 we are moving ahead with finally closing the ancient soundness issue https://github.com/rust-lang/rust/issues/82523 (originally tracked at https://github.com/rust-lang/rust/issues/27060): we are disallowing creating references to fields of packed structs. It seems like that will make winapi 0.2.8 fail to build:

    error[E0791]: `Debug` can't be derived on this `#[repr(packed)]` struct that does not derive `Copy`
        |
        |
    263 |           #[repr(C)] #[derive(Debug)] $(#[$attrs])*
        |
       ::: C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\winapi-0.2.8\src\mmreg.rs:290:1
        |
        |
    290 | / STRUCT!{#[repr(packed)] struct WAVEFORMATEX {
    291 | |     wFormatTag: ::WORD,
    292 | |     nChannels: ::WORD,
    293 | |     nSamplesPerSec: ::DWORD,
    297 | |     cbSize: ::WORD,
    298 | | }}
        | |__- in this macro invocation
        |
        |
        = note: this error originates in the derive macro `Debug` which comes from the expansion of the macro `STRUCT` (in Nightly builds, run with -Z macro-backtrace for more info)
    
    error[E0791]: `Debug` can't be derived on this `#[repr(packed)]` struct that does not derive `Copy`
        |
        |
    263 |           #[repr(C)] #[derive(Debug)] $(#[$attrs])*
        |
       ::: C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\winapi-0.2.8\src\mmreg.rs:299:1
        |
        |
    299 | / STRUCT!{#[repr(packed)] struct WAVEFORMATEXTENSIBLE {
    300 | |     Format: ::WAVEFORMATEX,
    301 | |     Samples: ::WORD,
    302 | |     dwChannelMask: ::DWORD,
    303 | |     SubFormat: ::GUID,
    304 | | }}
        |
        = note: this error originates in the derive macro `Debug` which comes from the expansion of the macro `STRUCT` (in Nightly builds, run with -Z macro-backtrace for more info)
    
    
    error[E0791]: `Debug` can't be derived on this `#[repr(packed)]` struct that does not derive `Copy`
        |
        |
    263 |           #[repr(C)] #[derive(Debug)] $(#[$attrs])*
        |
        |
       ::: C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\winapi-0.2.8\src\usbspec.rs:26:1
        |
    26  | / STRUCT!{#[repr(packed)] struct USB_CONFIGURATION_DESCRIPTOR {
    27  | |     bLength: ::UCHAR,
    28  | |     bDescriptorType: ::UCHAR,
    29  | |     wTotalLength: ::USHORT,
    ...   |
    34  | |     MaxPower: ::UCHAR,
    35  | | }}
        |
        = note: this error originates in the derive macro `Debug` which comes from the expansion of the macro `STRUCT` (in Nightly builds, run with -Z macro-backtrace for more info)
    
    
    error[E0791]: `Debug` can't be derived on this `#[repr(packed)]` struct that does not derive `Copy`
        |
        |
    263 |           #[repr(C)] #[derive(Debug)] $(#[$attrs])*
        |
       ::: C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\winapi-0.2.8\src\winusb.rs:8:1
        |
        |
    8   | / STRUCT!{#[repr(packed)] struct WINUSB_SETUP_PACKET {
    9   | |     RequestType: ::UCHAR,
    10  | |     Request: ::UCHAR,
    11  | |     Value: ::USHORT,
    12  | |     Index: ::USHORT,
    13  | |     Length: ::USHORT,
    14  | | }}
        |
        = note: this error originates in the derive macro `Debug` which comes from the expansion of the macro `STRUCT` (in Nightly builds, run with -Z macro-backtrace for more info)
    
    For more information about this error, try `rustc --explain E0791`.
    

    It looks like current versions of winapi avoid that error by deriving Copy for those structs.

    I am not sure if there is anything you want to do about this -- winapi 0.2.8 seems to not be supported any more. However, given how widely used this crate is, it still might make sense to do a patch release so that people can fix their build with cargo update. If you want to do that, I'm open to waiting a bit before landing the rustc PR so that you can get the patch release out first.

    opened by RalfJung 3
Owner
Peter Atashian
Writes software in Rust and C++. Is fluffy.
Peter Atashian
nginx bindings for Rust

nginx-rs This crate provides nginx bindings for Rust. Currently, only Linux is supported. How to Use Add nginx crate to Cargo.toml [dependencies] ngin

ArvanCloud 104 Jan 2, 2023
Rust bindings for iptables

Rust iptables This crate provides bindings for iptables application in Linux (inspired by go-iptables). This crate uses iptables binary to manipulate

Navid 63 Nov 17, 2022
Rust friendly bindings to *nix APIs

Rust bindings to *nix APIs Documentation (Releases) Nix seeks to provide friendly bindings to various *nix platform APIs (Linux, Darwin, ...). The goa

null 2k Jan 4, 2023
Rust bindings for the FreeBSD capsicum framework

capsicum Contain the awesome! Rust bindings for the FreeBSD capsicum framework for OS capability and sandboxing Prerequisites Rust, Cargo, and FreeBSD

Dan Robertson 52 Dec 5, 2022
Idiomatic inotify wrapper for the Rust programming language

inotify-rs Idiomatic inotify wrapper for the Rust programming language. extern crate inotify; use std::env; use inotify::{ EventMask, Watch

Hanno Braun 220 Dec 26, 2022
Rust library for filesystems in userspace (FUSE)

Rust FUSE - Filesystem in Userspace About fuse-rs is a Rust library crate for easy implementation of FUSE filesystems in userspace. fuse-rs does not j

Andreas Neuhaus 916 Jan 9, 2023
Rust implementation of a FreeBSD jail library

libjail-rs libjail-rs aims to be a rust implementation of the FreeBSD jail(3) library. While feature parity is a goal, a one-to-one implementation of

fubarnetes 38 Sep 27, 2022
Rust bindings to Windows API

winapi-rs Documentation Official communication channel: #windows-dev on the Rust Community Discord This crate provides raw FFI bindings to all of Wind

Peter Atashian 1.6k Jan 1, 2023
Windows-rs - Rust for Windows

Rust for Windows The windows crate lets you call any Windows API past, present, and future using code generated on the fly directly from the metadata

Microsoft 7.7k Dec 30, 2022
Use Thunk to build your Rust program that runs on old Windows platforms, support Windows XP and more!

Use Thunk to build your Rust program that runs on old platforms. Thunk uses VC-LTL5 and YY-Thunks to build programs that support old platforms. So, ho

null 6 May 21, 2023
Rust port of the official Windows Driver Samples on Github. Leverages windows-drivers-rs

Rust Driver Samples This is a Rust port of the driver samples from the original Windows Driver Samples on Github. The repository provides examples and

Microsoft 80 Oct 10, 2023
Send Windows 10 styled notifications on Windows 7.

win7-notifications Send Windows 10 styled notifications on Windows 7. Note: This crate requires a win32 event loop to be running, otherwise the notifi

Tauri 9 Aug 29, 2022
Switch windows of same app with alt + ` on windows pc.

Windows Switcher Switch windows of same app with alt + ` on windows pc. 250k single file executable downloaded from Github Release. No installation re

null 172 Dec 10, 2022
Check if the process is running inside Windows Subsystem for Linux (Bash on Windows)

is-wsl Check if the process is running inside Windows Subsystem for Linux (Bash on Windows) Inspired by sindresorhus/is-wsl and made for Rust lang. Ca

Sean Larkin 6 Jan 31, 2023
Windows Capture Simple Screen Capture for Windows 🔥

Windows Capture   Windows Capture is a highly efficient Rust library that enables you to effortlessly capture the screen using the Graphics Capture AP

null 3 Sep 24, 2023
Rust docs for the Windows API

Windows API documentation for Rust This is an experimental documentation generator for the Rust for Windows project. The documentation is published he

Microsoft 52 Dec 9, 2022
Attempts to suspend all known AV/EDRs processes on Windows using syscalls and the undocumented NtSuspendProcess API. Made with <3 for pentesters. Written in Rust.

Ronflex Attempts to suspend all known AV/EDRs processes on Windows using syscalls and the undocumented NtSuspendProcess API. Made with <3 for penteste

null 5 Apr 17, 2023
Windows Native Undocumented API for Rust Language 🔥

Windows Native   The Windows-Native Rust library provides a convenient and safe way to access the native Windows undocumented APIs using the Rust prog

null 3 Aug 22, 2023
High-level Rust bindings to Perl XS API

Perl XS for Rust High-level Rust bindings to Perl XS API. Example xs! { package Array::Sum; sub sum_array(ctx, array: AV) { array.iter().map(|

Vickenty Fesunov 59 Oct 6, 2022
Rust bindings for the C++ api of PyTorch.

tch-rs Rust bindings for the C++ api of PyTorch. The goal of the tch crate is to provide some thin wrappers around the C++ PyTorch api (a.k.a. libtorc

Laurent Mazare 2.3k Jan 1, 2023