3 ms·

Well, you said it yourself. "WndProc". These abbreviations is something you will see frequently and you will have to spend time memorizing them. Better identif

Well, you said it yourself. "WndProc". These abbreviations is something you will see frequently and you will have to spend time memorizing them. Better identifiers are possible. e.g: https://wiki.libsdl.org/SDL_CreateWindow https://wiki.libsdl.org/SDL_CreateWindow . CreateWindow, not "WndProc" or some ambiguous abbreviation. If you want to turn your job into playing hangman all day and guess what the hell the actual abbreviated words are, use the Windows API.

Tobba_ 9y ago
If almost your entire userbase is running Windows you're gonna end up needing to deal with it anyways, one way or another. You can at least be glad to be dealing with Win32, which other than user32 (which is a bit crazy for compatibility reasons, though I'm not sure if X11 is much better) is actually far more reasonable than it's contemporaries. Compare doing fast async file I/O on Win32 vs POSIX. On Win32 it just boils down to creating an IOCP pipe, creating some worker threads, setting up the file handles and using the right flags in read/write calls. It's a bit obtuse, but the code that does it ends up reasonable, and it's the same drill for sockets. Doing that on POSIX? You get blocking, uncancelable I/O calls and threads to work with, that's it. Good luck, though the documentation involved is far simpler (or just use something like libuv if you value your sanity). Using a library here would be preferable, but I really don't see why using Win32 would be the problem and not the fact that it's non-portable.
- partycoder 9y ago
  Yes, you can use libuv. It's a crossplatform async I/O, with a sane API. Then, guess what: Android, iOS, macOS, Linux, BSD... all of them are in some way or another, similar at the low level. Windows API is unique, like TempleOS. But even the TempleOS API makes more sense, is more consistent and is better thought than the Windows API.
  - Tobba_ 9y ago
    While the Windows API can be pretty clunky and has a ton of leftover cruft, and the UI-related APIs aren't too great thanks to being compatible with Windows 95 (use a toolkit if you want controls), it'd be really hard to argue that any of those (except maybe TempleOS; I haven't looked at it) are any more sane than Win32. You get pretty unified support for async notification through IOCP, which can be used for sockets, files and a few more things. On most of the systems you listed you'd get some flavor of kqueue at best, and probably only for sockets. On the NT side of things you have the handle system, which serve the same purpose as file handles without pretending that "read", "write", and "ioctl" are the only operation any of them will support (plus socket operations, if you want to include those). It also provides the ability to transfer them between processes (with access control!) and place them in a (semi-)global namespace without having to muck around with the actual filesystem. Not to mention basic operations like reading information about a process doesn't involve having to parse text that can contain semi-arbitrary strings (/proc/<pid>/stat contains the filename near the start, have fun) I can't say I like Windows as an OS, but API-wise? Not fantastic either, but compared to every other major desktop OS/kernel it's a saint, and provides more functionality. In the context of complex 3D games; if you need to do something like transfer 1GB of data from disk to GPU memory as fast as physically possible, you have to care about this.
    - partycoder 9y ago
      OK, in fairness, some portions of the Windows API are well though out as you mention. Some people may also argue that other APIs like Direct3D have a more convenient design. The UNIX philosophy ("Everything is a file") has pros and cons. It makes interoperability fairly trivial, and being a filesystem it has access control capabilities. If you want to have something similar to the Windows' IO Completion Ports (IOCP) paradigm you can make use of https://www.kernel.org/doc/Documentation/scheduler/completion.txt https://www.kernel.org/doc/Documentation/scheduler/completio...
      - Tobba_ 9y ago
        It really hard to compare them fairly since they're quite different in scope; X11 wouldn't exactly be considered a Linux API. Win32 is also split between several modules and the functions don't quite correspond to the syscalls; it's basically a bunch of wrappers around the actual NT API, win32k and some userspace servers. So it's really hard to draw a line somewhere if you wanted to compare them.
ygra 9y ago
CreateWindow is CreateWindow in Win32 as well. How you name the function that handles messages is up to you. WndProc is merely a convention. It's not like a function pointer has any name, so for the API it's irrelevant.

Tobba_ 9y ago

If almost your entire userbase is running Windows you're gonna end up needing to deal with it anyways, one way or another. You can at least be glad to be dealing with Win32, which other than user32 (which is a bit crazy for compatibility reasons, though I'm not sure if X11 is much better) is actually far more reasonable than it's contemporaries. Compare doing fast async file I/O on Win32 vs POSIX. On Win32 it just boils down to creating an IOCP pipe, creating some worker threads, setting up the file handles and using the right flags in read/write calls. It's a bit obtuse, but the code that does it ends up reasonable, and it's the same drill for sockets. Doing that on POSIX? You get blocking, uncancelable I/O calls and threads to work with, that's it. Good luck, though the documentation involved is far simpler (or just use something like libuv if you value your sanity). Using a library here would be preferable, but I really don't see why using Win32 would be the problem and not the fact that it's non-portable.

partycoder 9y ago
Yes, you can use libuv. It's a crossplatform async I/O, with a sane API. Then, guess what: Android, iOS, macOS, Linux, BSD... all of them are in some way or another, similar at the low level. Windows API is unique, like TempleOS. But even the TempleOS API makes more sense, is more consistent and is better thought than the Windows API.
- Tobba_ 9y ago
  While the Windows API can be pretty clunky and has a ton of leftover cruft, and the UI-related APIs aren't too great thanks to being compatible with Windows 95 (use a toolkit if you want controls), it'd be really hard to argue that any of those (except maybe TempleOS; I haven't looked at it) are any more sane than Win32. You get pretty unified support for async notification through IOCP, which can be used for sockets, files and a few more things. On most of the systems you listed you'd get some flavor of kqueue at best, and probably only for sockets. On the NT side of things you have the handle system, which serve the same purpose as file handles without pretending that "read", "write", and "ioctl" are the only operation any of them will support (plus socket operations, if you want to include those). It also provides the ability to transfer them between processes (with access control!) and place them in a (semi-)global namespace without having to muck around with the actual filesystem. Not to mention basic operations like reading information about a process doesn't involve having to parse text that can contain semi-arbitrary strings (/proc/<pid>/stat contains the filename near the start, have fun) I can't say I like Windows as an OS, but API-wise? Not fantastic either, but compared to every other major desktop OS/kernel it's a saint, and provides more functionality. In the context of complex 3D games; if you need to do something like transfer 1GB of data from disk to GPU memory as fast as physically possible, you have to care about this.
  - partycoder 9y ago
    OK, in fairness, some portions of the Windows API are well though out as you mention. Some people may also argue that other APIs like Direct3D have a more convenient design. The UNIX philosophy ("Everything is a file") has pros and cons. It makes interoperability fairly trivial, and being a filesystem it has access control capabilities. If you want to have something similar to the Windows' IO Completion Ports (IOCP) paradigm you can make use of https://www.kernel.org/doc/Documentation/scheduler/completion.txt https://www.kernel.org/doc/Documentation/scheduler/completio...
    - Tobba_ 9y ago
      It really hard to compare them fairly since they're quite different in scope; X11 wouldn't exactly be considered a Linux API. Win32 is also split between several modules and the functions don't quite correspond to the syscalls; it's basically a bunch of wrappers around the actual NT API, win32k and some userspace servers. So it's really hard to draw a line somewhere if you wanted to compare them.

ygra 9y ago

CreateWindow is CreateWindow in Win32 as well. How you name the function that handles messages is up to you. WndProc is merely a convention. It's not like a function pointer has any name, so for the API it's irrelevant.