I now have a slightly better understanding of rust with the help of the rust book. I want to ask the people how to display a black square, for example a 400px by 400px square.
I want to do this without crates or librairies or anything other than rust programmation and win32 api or winRT native api calls. (rust if my first real programming language, I know nothing about win32, even less so how to call it with rust).
In other words, I'd like to find book recommendations or informations about how to make the simplest gui (an executable file which would create a black square) solely relying on a rust written program.
The reason is because I would like to understand how gui works on windows because I find no information about it.
Although you mentioned you especially do not want external crates and libraries, I’d say the simpler and more recommended approach is just start with a library like softbuffer : first get its example code running, then understand what really lies under its abstraction: surfaces, windows(from winit), event loop and control flows(also from winit).
The other direction is get a Windows SDK book (like Programming Windows 5th edition by Charles Petzold), and port its routines from C to Rust. This is basically building the earlier mentioned abstractions from scratch. This matches your schedule more closely, but it’s harder and the resulting program is simply noiser until you cleaned up everything into its own abstractions.
You can take a look at the crate. It has also a test program, so you do not need any external crate for that. I did it for Rust 1.60, so it may require minor tweaks for the current Rust 1.91.
There are 2 main UI APIs in The Windows: GDI and DirectX.
GDI was part of Windows from the very beginning. The idea is you have so-called "GDI context" which can be used to draw primitives like FillRect.
A Typical Windows App creates a window (CreateWindow) and binds event loop to it. Each time Windows wants your window to be redrawn, it sends you a message (i.e WM_PAINT) and you use GDI to draw something.
Then, Microsoft created GDI+ with C++ class wrappers and MFC (a pack of ready-to-use widgets) and so on.
GDI and Even loop are perfect for Windows forms, but can't be used for games. Game developers usually need direct, exclusive access to hardware, and they do not need an external messages like WM_PAINT: they know better when to redraw things (g: "game loop"). Moreover, they need to change resolution, use full screen and so on.
For these folks, DirectX was created. It had "DirectDraw" API (which was then replaced by Direct2D and Direct3D). Windows also supports some other API (i.e OpenGL).
Now, answering your question: Try to create a simple Window with Event Loop and fill it with black color using GDI.
Ah yes. The classic "this is the simplest example of a UI, surely? This should be like 20 lines" - cue an introduction to 50 years of the industry stumbling through a field of rakes trying to figure out how to do the main thing people use a computer for.
Currently, and shockingly, there's isn't actually any reasonable default "native" (platform provided) and low level option for GUI (e.g. controls) on Windows, unlike MacOS with (currently) SwiftUI, or GNOME or KDE on Linux.
Assuming the intent here is to understand "how do windows GUI applications actually work under the hood", the unfortunate answer is "a crapload of work"
Historically, and probably the best match for what you're actually after, is GDI as mentioned by @throwable-one - definitely check that out, but it's pretty ancient and pretty much nothing you use in Windows still uses it, so it's a pretty bad start for understanding current Windows GUI itself... but it is a decent start for understanding the classic Windows windowing and event loop model (that is, CreateWindow, GetMessage, WM_* etc. - but not CreateWindow("BUTTON", .. or FillRect etc.), which nearly all applications do still use - just they create the window solely to use it as a canvas to draw on with (eventually) Direct3D (or, much more rarely, OpenGL or Vulkan)
There's a newer "Windows App Package" model that is pretty annoying to work with due to the packaging / registration model - it was created for the Microsoft Store originally, though I believe you can distribute it outside now. Here's the equivalent empty sample app:
That does allow you to use the XAML rendering model, but that's very much not a "simple minimal example", and very few non-Microsoft applications use any of this, so I'll quit while I'm behind.
Anything more than the absolute most trivial blank-screen output with bare Direct3D is also kind of a nightmare: there's no Direct3D 11 sample but the 12 sample gives a rough idea:
Direct3D 11 is a bit more reasonable, probably about half that length, while Vulkan is even worse than that example. OpenGL is all over the place depending on what, exactly, you do with it, but for various reasons it's not a great long term choice on Windows.
To re-emphasize, while this is pretty much what's eventually what's underneath nearly every application you use on Windows, this doesn't even get you anything like a GUI. Without any external libraries you would have to re-implement everything - layout and rendering for components and text (very different!); input including hit-tests, focus management, event dispatching; animation, caching, theming, any shadows or other effects, and so on and so forth. Literally years of work, that other people have attempted to provide packaged up as various libraries.
The current most popular approach for doing GUI on Windows is pretty much just "put a browser window in a box", the second is probably using an existing, probably cross-platform UI library like Qt, though the options there are pretty dismal in my opinion.