I really enjoyed the demoscene back in the 90s. Was never a part of it but I was always fascinated by the effects and music and ascii art that these guys created.
A BBS in my city always had the latest e-zines like Reality Check Network and Affinity, and others I forget. Reading up on the scene and about groups like Razor1911 was something I spent a lot of time on when I was younger.
I'm in the same country. Another big reason to use a CB over a phone is that it's illegal to touch a phone while driving. No such restriction applies to CB radios.
Though, as someone who's done a number of those interviews over the years, I'd replace the word truthful with manner that the interviewer regards as truthful
They're hard for me because the events that a lot of people consider achievements don't really stand out in my memory. Often I tend to forget they happened.
I've solved some programming problems that I considered quite mundane and unremarkable, yet others think it was some great achievement.
While it might have been hard at the time, in hindsight the events seem unremarkable and just me doing my routine duties.
> "Write about a time during your university studies in which you faced a difficult problem, and what you did to overcome it."
I guess the university example I could spin a story about how I failed a subject and had to repeat it and got high marks the second time round. The thing is I probably won't remember the event if I'm in an interview and under pressure.
When I started writing this post, I couldn't think of anything difficult that I had to overcome in my CompSci degree. It took me a while to even remember failing that subject, and in hindsight I don't have any emotional attachment to the event. It just doesn't stand out in my memory as remarkable or interesting or even difficult. I did change up my tactics the second time around and did quite well in the subject, so I have material for a story.
The problem is most of the time I don't even remember failing that subject. Even if I did remember, I'd probably dismiss it as I don't remember it being difficult.
So what if it's using unbounded strcpy's all over the place? It has basically no attack surface. He wrote it for himself, not for criticism from the HN hoi polloi
I didn't point that out so I could be the smartest person in the room and I certainly don't subscribe to the whole rewrite-the-world in rust.
The sheer amount of time I spent debugging problems caused by buffer overruns and other daft problems is immense. It's literal days of my life that could have been saved had safer APIs been created in the first place.
It's a cool toy program and I encourage the learning but maybe let's try and avoid unnecessary problems.
It's not really suitable for general purpose programming like the OP is doing. It won't null terminate the string if the buffer is filled, which will cause you all sorts of problems. If the buffer is not filled, it will write extra null bytes to fill the buffer (not a problem, but unnecessary).
On freebsd you have strlcpy(), Windows has strcpy_s() which will do what the OP needs. I remember someone trying to import strlcpy() into Linux, but Ulrich Drepper had a fit and said no.
You just never assume a string is null terminated when reading, using strnlen or strncpy when reading as well.
Not really possible when dealing with operating system level APIs that expect and require null-terminated strings. It's safer and less error-prone to keep everything null terminated at all times.
Or just write in C++ and use std::string, or literally any other language. C is terrible when it comes to text strings.
There is something I like about win32 gui programming. It's a little idiosyncratic, but if you read Raymond Chen's blog you'll see why.
The win32 API has its origins on the 8088 processor and doing things a certain way results in saving 40 bytes of code or uses one less register or something.
I wrote a lot of toy gui apps using mingw and Petzold's book back in the day. Writing custom controls, drawing graphics and text, handling scrolling, hit testing etc was all a lot of fun.
I see in your app you're using strcpy, sprintf. Any kind of serious programming you should be using the length-checked variants. I'm surprised the compiler didn't spew.
You'll also find that the Win32 API has a lot of replacements for what's in the C standard library. If you really want to try and get the executable size down, see if you can write your app using only <Windows.h> and no cstdlib. Instead of memset() you've got ZeroMemory(), instead of memcpy() you've got CopyMemory().
At some point writing raw C code becomes painful. Still, I think doing your first few attempts in raw C is the best way to learn. Managing all the minutiae gives you a great sense of what's going on while you're learning.
If you want to play more with win32 gui programming, I'd have a look at the WTL (Windows Template Library). It's a C++ wrapper around the win32 API and makes it much easier to reason about what's going on.
I don't use any of those, and I've never felt the need for them really. Is Make and Vim not an IDE?
None of those existed when I started to code at my first dayjob and I've never really seen the value in them.
I find it interesting you think that go-to-definition isn't possible without a language server. I was doing that long before lang servers existed.
When I want to look a function signature up, well there's two ways I do it.
1) vim + ctags and Ctrl-] will take you there (usually, sometimes it gets confused).
2) grep (or nowdays, ripgrep) the codebase for the name of the function (in another window).
As for remembering what is where. Good organization helps. After time I tend to develop a mental model of what is where and I'll just find myself popping over to the other terminal and opening a file in vim to find what I need.
You can take syntax highlighting from my cold dead hands, though.