News for hackers. Stuff that matters.
Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by pcwalton on Thursday March 23, 2017 @12:58PM (#13941596)
> Not to mention that the Windows API UI toolkit, while bad, is sane compared to the web stack.

Completely disagree. Charles Petzold's HELLO.C is hundreds of lines of code. Hello World on the Web is, well, "Hello world!".

"Sane" environments don't force you to make up a distinction between "long pointers" and "pointers" if you want to conform to the house style in order to match 16-bit x86 real mode. Or route all events through one WndProc, forcing use of "message crackers" to poorly recreate the ergonomics of addEventListener. Or have to recreate the vector graphics stack not once but twice in order to deal with the lack of forward thinking (GDI, GDI+, Direct2D). Or deal with incredible apartment threading complexity to maintain VB6 compatibility. Etc. etc.

If you had said .NET, maybe. But Petzold-style Win32 is bad.

Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by coldtea on Thursday March 23, 2017 @04:00PM (#13943665)
>Completely disagree. Charles Petzold's HELLO.C is hundreds of lines of code. Hello World on the Web is, well, "Hello world!".

It's actually 87 lines of code, with a disclaimer comment, ample empty lines, a callback to play a wav when clicked, and an error message for when it's not run on NT. So, like 30-50 lines of actual Hello World necessary code. And that includes the starting up boilerplate.

That's about as relevant as complaining about the large binary size of a hello world program in a language creating static binaries. It might be larger than expected, but it usually includes a whole runtime. So once you add actual code, the binary's size doesn't scale linearly with the code size.

For comparison, a modern CSS "reseting" file, which just removes empty values is usually larger than the hello.c example.

This is the problem with trivial/contrived examples. They don't show you how the thing you're discussing scales in actual use.

In this case, the hello world in HTML is not representative of what you need to do to create a medium/large SPA in HTML.

And the old Windows api you could always wrap in higher order stuff, or even use as a basic layer to create your own UI library (still native).

The web stack, because of how it is done, you can't.

Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by userbinator on Thursday March 23, 2017 @11:22PM (#13946352)
It's actually 87 lines of code, with a disclaimer comment, ample empty lines, a callback to play a wav when clicked, and an error message for when it's not run on NT. So, like 30-50 lines of actual Hello World necessary code. And that includes the starting up boilerplate.

Petzold's Hello World is far more than what I'd consider a Hello World in Win32, because in addition to what you noted, it also creates a "full" window with all the associated complexity of managing its drawing yourself. A more suitable Win32 Hello World is not that much more complex than the traditional C one:

    #include <windows.h>
    #include <winuser.h>

    int main() {
        MessageBox(0, "Hello World!", "Hello World!", MB_OK);
    }
From there, one can progress onto "dialog-based applications", where the bulk of the layout is declarative (in the resource file) and the C part is two functions, a callback for messages and a main() which just calls DialogBoxParam(). No WM_PAINT handling is necessary for those. A "full window" application is actually not necessary for many use cases. I've been working with Win32 for over a decade and a half and written at least a dozen little apps for various things, but the vast majority of them are not "full window" apps.

In other words, I'd say Petzold was at least partially responsible for giving the impression that Win32 is impossibly complex even to start with. Fortunately others have come up with better introductions like http://www.winprog.org/tutorial/ or even https://win32assembly.programminghorizon.com/tutorials.html since then, but it seems that the damage has already been done and a whole generation of programmers have gotten the "Win32 is hard" notion embedded into their minds.

Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by pjmlp on Thursday March 23, 2017 @02:39PM (#13942751)
You are forgetting the magic CSS incantations, which are browser and version dependent, to accelerate something that is just granted on any native UI toolkit.
Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by pcwalton on Thursday March 23, 2017 @02:53PM (#13942922)
I agree that the paint/compositing distinction is bad (see my reply to Paul Irish), but Win32 has just an opaque a distinction. GDI is much worse for modern hardware acceleration than the Web is.
Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by pjmlp on Thursday March 23, 2017 @07:30PM (#13945319)
GDI is a dead worse, already replaced by better solutions for anyone that cares to use them, yet it still scales better than most web stuff.
Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by eltoozero on Thursday March 23, 2017 @03:07PM (#13943086)
Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by throwaway2048 on Thursday March 23, 2017 @02:22PM (#13942552)
Complaining that win32 has to do stupid things to get basic features in comparison to the web seems pretty laughable.
Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by pcwalton on Thursday March 23, 2017 @02:40PM (#13942763)
Why? The consensus opinion here seems to be that Win32 is a better API than the Web. I'm pointing out that this is an extreme case of rose-colored glasses.
Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by sqeaky on Thursday March 23, 2017 @03:47PM (#13943511)
I have had to use the win32 API within the last year. I left that job, I regret nothing.

As much as I want as few layers between me and the hardware as possible, I would rather have many sane layers like much of the web than 1 insane layer like the win32 API. It doesn't follow good C, C++, std library or other conventions. Many functions have multiple poorly documented modes based on which structs you pass are empty or null pointers. It also just fails often for no reason I can understand, and the distinction between windows application and console is quasi magical and counterproductive.

Posix... Is a blessing by comparison. Every time I need to touch it it take me something like a single hour and I have a function that works reliably and just does what I need. Until we get to X11 and manipulating those windows. Then I just want to punch everything, but at least X11 works once the code is written, even though its inside out and backwards.

Now I just strongly prefer to use a good library to get at OS facilities. Things like SDL, boost or Intel Threading build blocks, etc. They are fast and generally tight enough I can open them and understand down to the hardware when I want.