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.
But that's because we are in era where 90% of effort spent on any apps is to make it “feel fresh” and “attractive”, not to provide an actual functionality.
Is this some king of sick joke or do you genuinely believe that? All these controls that were made back in 1985 are still there and there are many new ones. The problem is that for some unfathomable reason Microsoft decided that it needs to start from scratch… two times which created a mess. But all these things that were added to Windows back in 1983 are still there, they are still usable.
Thank you very much for all the information, this is very complicated and I'd still be searching how to display one single pixel, without a window, just an executable file that displays a single pixel without gui or anything else. I think that the directx program could have a way of doing it from what I'm reading there.
Thank you very much for all the information, this is far more complicated than what I envisaged before. I will try to see the simplest way of displaying one single pixel, without anything, without a window or gui, just a single pixel. Maybe directx would be the option, thank you all people for all your answers.
That's not an option, on a modern computer. It was trivial on mini-computers half-century ago where app “owned” the computer, but all modern OSes are specifically made to “isolate” program from hardware and as such they prevent such attempts. You program, in a modern times, is just a “plugin” for the OS, not a standalone thing.
So you have to pick between two options:
Comply with OS conventions and study them and use them.
Switch to embedded realm where hardware access is allowed and showing a pixel is trivial… but many other things are complicated.
Thank you for these informations, I now see the reason behind all this, it is necessary for the operating system to work correctly, I will have to look for embedded programming
The suggestion of softbuffer (alternatively pixels) crates will give you this, by giving you a buffer to draw arbitrary pixels to in software (that is, as just an array) which they then draw to the screen with DirectX.
It's really about what you're actually interested to learn here, because "GUI" is a huge area and is particularly complex on Windows.
You might (not) be suprised to learn (at this point) that such a (seemingly trivial) task is beyond any "simplest way" you could possibly imagine (yet). More on that, towards the end.
I second this. Do not bother with the 6th edition (featuring C# and XAML). It has strayed far too much from the intent, and the foundation, of its predecessor. Basic C/C++ is the way to go. Given:
That is definitely what you're looking for.
It might not be what you believe you're looking for, however: given some of the (rather premature) conclusions you seem to have come to after finishing the book on the Rust language alone. Yet if you're just looking to make create some bare-bones GUI application for Windows, that's the way.
The hardest part about learning anything new is trying to figure out not just the answers to the questions you know you don't have yet, but the kind of questions you're meant to be asking.
The former, in your case, is "how do I display a square, on Windows, using only Rust?"
The latter, depending on how deep you're willing to go down the rabbit hole, might be:
how do I tell Windows to display a square?
what happens under the hood when it displays this square?
how far can I reach under this hood?
what happens at the hardware level beneath it all?
how do I tell the hardware itself to display the square I want it to?
am I willing to write my own OS from scratch?
For #1 to #3: read Petzold.
The rest of the questions you're not meant to ask quite yet. Not because it will melt away your brain and glue your eyelids shut forever more; but because knowing the basics about Rust the language alone is nowhere near enough to be able to piece together all that's going on here.
Short version of #4: the hardware level is managed by the OS. Every piece of hardware. That includes your keyboard, mouse, memory, processor, graphics card / chipset, hard / solid state drive, network card, as well as any and all devices you've ever connected to your PC.
Short version of #5: write your own OS. Your own kernel. Your own interrupt handler. Your own graphics stack. Your own everything. When you're done - just tell it to display your square.
For #6: personally, I wouldn't recommend it. The choice is your own to make, though.
This answer is in the context of the question, that being seemingly "how does GUI work in Windows, from scratch"
While there are still the standard controls and GDI (and they have been mentioned), learning them won't teach you anything about how nearly any application you're actually looking at works - they are native and low level, but not default - like the APIs I mentioned for other platforms are.
Why UIs started moving to webviews is a complicated question, much more than "we wanted drop shadows." One aspect is that it's simply easier to find UI designers and UX developers familiar with web tech and it's capabilities, another is that the endless complaints about "a new day, a new web framework to learn" actually did result in a decent amount of improvement in UI architecture over traditional widget pick and place, which has resulted in user expectations significantly jumping (or at least shifting). But there's a lot of contributing causes, and possibly the biggest is that frankly the alternative options are just kind of terrible.
Is it really an improvement if it achieves the same thing with a more expensive developers (pinnacle of traditional GDI controls development is VB6 which non-technical users can use to develop applications without coding… pinnacle of post-GDI development is… what have we achieved there, really? the need to use AI to do the most trivial change to the app because no one knows how exactly it's done in the framework-of-the-year because last year approach is no longer works?).
I would say that both user expectations and app developers focus is now spent 90% (if not 99% of time) on something that's not needed and not useful for any functionality… but that's perfectly Ok, as we know. Remember? Don’t think that they’re looking at the functionality. They’re not. They want to see pretty pixels.
If you accept that functionality doesn't matter and pretty pixels do matter then everything is fine. Even Rust is not immune, just compare the previous version of the official wen site (still available, today) to the current version. In old version you may see how Rust looks like, at least, but these days it's no longer important, it's not even important to make web site readable, what's important is to make it look “pretty enough” to be “taken seriously”.
Nah, the contributing case is the users desire for bling. Nothing more, nothing less. It works, I guess, even if creates immense complexity and reduces reliability. I guess we may afford it, these days: computers are no longer crashing when you breathe on the wrong naturally, it's time to pile UI designer “visions” till they would do that… still a bit sad to see.
Still doesn't explain why Microsoft needed to abandon GDI to achieve that: Apple and Google are finding the way to spend resources on things like Liquid Glass and Material 3 Expressive just fine without needed apps rewrite every couple of years… I guess Microsoft wanted to ensure that people would spend time doing that and thus couldn't chase Microsoft, maybe? IDK, the end result was more-or-less abandonement of what Microsoft offered and switch to web technologies that, at least, are cross-platform.
Plus Microsoft needs to carry forward all these abandoned techs which no one uses (there are two kinds of Microsoft's universal apps — but how many developers do you know who develops either of these?).
In short, as someone that's had to deal with this crap against my will for most of my job, yes, absolutely it's an improvement. The browser UX model is light-years more capable than the traditional widget toolkit model. It's still absolutely awful, but it really does just seem to be an incredibly difficult problem to solve.
Specifically, interfaces now are expected to be dynamically resizable, support translation on the fly, have significantly reduced or eliminated modal interaction, support arbitrary nesting of controls dynamically driven by data while still maintaining sufficient affordances to be readable, communicate with high latency and fallible remote backends, often while receiving live updates, and all with much higher bars for responsiveness and accessibility. Probably lots more I'm not considering.
And yes, web let's you also do all that while arbitrarily styling everything and adding lots of little shiny touches too, and also seamlessly distribute updated versions at a whim.
Those expectations became standard specifically because web tech demonstrated the ability to do so, and far more easily than the equivalent native toolkits. Does it still suck? Yes, absolutely so. But that's because GUI is, actually, just hard when you break down the requirements.
Anyway, this all is starting to get a bit far afield of the thread topic, such as it is.
TBH, bare GDI was not the only way to create UI for Windows: There were Qt, WxWidgets, MFC, I even remember OWL from Borland and so on. For .NET there were WinForms (GDI-based) and WPF (which, I believe, was DirectX-based and supported much more layouts, resizable components, nested components, data binding and so on), but I agree that React+Material (just an example of modern approach) could be a better choice. However:
Native UI (MFC, WxWidgets, GDI Window with BUTTON class) obeys Windows look and feel (colors, font sizes and so on), Web doesn't.
Native UI might be 500 times smaller (both in terms of RAM and binary size) and run on 20 years old hardware or tiny VPS. There are Windows servers without UX, when used as domain controllers they might have 1GB RAM, one doesn't run browser there (but they still support GDI!))
From the other hand, web-based solution is:
Almost cross-platform, as any modern OS has a browser. Write once.
Much simpler to develop, especially for complex designs
Could be delegated to UI developers (aka front-end devs) which makes nice "backend/frontend" separation.
It draws the white rectangle, because my background is black. I ask AI for a C example and simply copied it in on_paintfunction. I do not use Cargo, but you can write Cargo manifest file easily.
PS Maybe it was so easy for me, because I wrote a book for Windows programming using Turbo Pascal. It was available is SF BA libraries 10 years ago, but no more.
