Learning ancient api sounds quite fitting for people who use ancient sites, don't you think?
http://laurencejackson.com/win32/
msdn library
http://web.archive.org/web/20170914050446/http://www.catch22.net/tuts/neatpad/4
Visual Studio 2005 has a more complete offline winapi documentation that goes back to windows 95, first link here only goes back to windows 2000.
I'm surprised that NTFS has a built in compression.
https://docs.microsoft.com/en-us/windows/win32/fileio/file-compression-and-decompression
LZOpenFile, LZCopy, and LZClose
Learned that there are very similar functions in winapi, SetWindowLong and SetWindowLongPtr. SetWindowLong is the older one, but it works only with long (32-bit) numbers, and SetWindowLongPtr works with 32-bit numbers on 32-bit systems and 64-bit numbers on 64-bit systems. Actually, header looks something like that:
#ifdef _WIN64
...
#else
#define SetWindowLongPtrA SetWindowLongA
#define SetWindowLongPtrW SetWindowLongW
#endif
and it is literally an alias on 32bit computers.
I fear that this function alone may cause my program to not work correctly, if I run 32-bit program on 64-bit computer. I have code like this
edit_procedure_old = (WNDPROC)SetWindowLong(hEdit, GWL_WNDPROC, (addr)edit_procedure);
This will probably return garbage if the return value doesn't fit in 32 bits. Microsoft probably worked around it by placing all control procedures in a lower address, but I have no idea if they actually did it or not.
I think I will just make my own control instead, I don't like the default one anyway. Then I wouldn't need SetWindowLong.
The edit control in winapi is kind of weird, pressing ctrl-backspace in it results in an empty box appearing in the window (instead of the last word being deleted as I was expecting), and the message WM_CHAR with wParam==VK_F16(0x7f) being sent. You can see this behavior even in the default windows file explorer, when you rename a file, and in various other random places.
This is actually fixable though, again with SetWindowLongPtr GWLP_WNDPROC. And .NET edit control seems to work with ctrl-backspace well out of the box. I plan on getting rid of that control in my program and processing all WM_CHAR and WM_IME_* messages manually, I suspect it will be cleaner in the end.
DirectX 9 SDK
https://archive.org/details/dx9sdk
Not quite winapi, but close.
CreateFontIndirect is so much better than CreateFont, why didn't I use it before.
About what the hell GlobalAlloc is.
https://stackoverflow.com/questions/27151468/windows-api-clipboard-globallock-use-or-not-to-use
VirtualAlloc is better than all of this, but also the most annoying to use. GlobalAlloc, HeapAlloc all call VirtualAlloc in the end.
https://www.tilander.org/aurora2/Include_Windows.h/index.html
>But the MSVC compiler has an extension to do this, even though the standard explicitly tells you that you can not forward declare an enum.
Nuuuu, why your compiler can do things our caaaaan't, thats cheatiiiiiiin ;_;
>I've taken the habit to wrap windows.h inside another header with a heavy preamble and post include fixup (undef a whole bunch of crap).
That's a good idea actually. But of course this faggot didn't post any actual code, of course.
I always do #define WIN32_LEAN_AND_MEAN before doing #include <windows.h>, this cuts away quite a lot of trash.
Huh, standard edit control in windows supports ctrl-z, cool. It only undoes the last operation though. It also supports ctrl-shift-z and alt-backspace, but those all do the same thing.
type 111111
delete it
ctrl-z swaps between [111111] and empty line. The 111111 will be selected.
type 123456
delete 23
type fff
ctrl-z swaps between 1[23]456 and 1[fff]456
type 123456
delete 23
move to the end of the line
type 777
ctrl-z swaps between 1456 and 1456[777]
So I guess it keeps a second string array just for undo, but overwrites it every time that's not enough.
Interesting, if you type 123456, go between 3 and 4, and start deleting things in both directions, the entire string will still be saved in the undo, it doesn't matter if you use backspace or delete, if you move cursor, or if you select multiple characters at once before deleting, it will still store the entire thing as long as it connects to the previously deleted thing. But if you delete 6 5 4, and then start deleting 1 2 3, only the last 1 2 3 will be in the undo history.
http://www.ngedit.com/a_wm_keydown_wm_char.html
A confused guy being confused on what the fuck is going on with WM_KEYDOWN WM_KEYUP and WM_CHAR. Together we can be slightly less confused about WM_CHAR.
By the way, I listen to WM_KEYDOWN AND WM_KEYUP, and store the status of ctrl and shift keys manually. Then, in WM_CHAR, I just ignore everything if ctrl is pressed.
And if I don't need WM_CHAR in the first place, I just don't do TranslateMessage()
I feel more braindead than usual. I'm sitting there staring at the code and not sure what to do. Things I'm doing feel unnaturally complicated, I'm trying to do text edit control without relying on ones windows provides.
I defined those variables as
TCHAR input_field[INPUT_FIELD_MAX] = {0};
u4 input_field_widths[INPUT_FIELD_MAX] = {0};
u4 input_field_used = 0;
u4 input_field_cur = 0;
u4 input_field_selectionstart = 0;
But I have more than one line on the screen I want to be able edit, and I want to switch to one of those lines on pressing ctrl-e. I guess I'll store the contents of that field into another TCHAR[INPUT_FIELD_MAX] array when I switch to something else. I'll keep everything that is editable as TCHAR[INPUT_FIELD_MAX], this will simplify things, I don't want to reallocate the entire thing every time.
I think input_field should be a pointer, since I'm going to have more than one input_field.
How to get your windows executables a bit smaller. This is annoyingly complicated.
WndProc return value
https://stackoverflow.com/questions/4650566/correct-return-value-of-windowproc-in-a-win32-application
Correct return value of "WindowProc" in a Win32 application
Usually zero, but depends on a message.
For instance, for WM_CREATE, you should return zero to continue window creation, and -1 to fail and destroy the window. For WM_GETICON, you should return a handle to the icon for your window.
For messages that you do not explictly handle, you should call DefWindowProc, passing to it all the parameters to your window proc, and return its return value to the caller.