Hi,

I'm following the series and coding everything at the same time I watch it. I make my own changes but the code is basically the same. In day 022 I found something that works very differently to what Casey has and I assume it is because of my HDD writing speed, but I would like to confirm it. I checked the forums but couldn't find something similar to my problem. If it exists, I must have missed at a reference would be appreciated.

What happens is that in this episode, for every frame, we use the CompareFileTime WINAPI function to check the last writing time when the dll was loaded with the actual dll last write time, so when it's different we reload the dll.

The problem is that when that happens, the game would actually not load at all. But if I stopped in the debugger, the hot reload would work. After some fiddling, I discovered if I waited around 20 frames to reload since detecting the change, the hot reloading would almost always work.

I naturally assumed that the problem would be in the CopyFile call. I checked with GetLastError and effectively the error code is 0x20 (ERROR_SHARING_VIOLATION), which means that the file is locked by another process, which I assume is the compiler outputting the library.

Now, I have 2 questions:

1. Why is it that the Last Write Time changed even though the file was not freed? Not only that, but it changed a lot before the file was actually free. What file meta-data do I have to check to see if the file is actually done being written or it's just flat out polling the CopyFile call until it succeeds?
2. (much less important) Why did Casey's code work? Is it because much faster HDD, probably SSD?

Thanks for reading and (hopefully) answering such an archaic answer.
Casey, if you happen to read this, I love the series and have learned a lot from it. Keep up the good work.

I don't remember exactly in what day, but after first implementation Casey updated code for game dll reloading. Not sure what changed there.

Another possibility is your antivirus software. It may be locking newly created executable/dll files to scan them (I've seen this happen on my machine).

It's on the platform layer cleanup episode:
https://forums.handmadehero.org/j...videos/win32-platform/day024.html 42m45s

Thank you both. Effectively it seems some process is keeping a handle on the file, even though I still haven't identified which. I haven't checked the platform layer cleanup episode yet, but for know I use a short delay until I get to that part.

You can use tool like Unlocker to find what process have opened this file. Unlocker integrates into Explorer, so all you need to do is right click on file and select Unlock.

Alternative tool is Process Hacker. It is basically advanced Task Manager. It can show a lot of useful information about processes and handles in system (including who has opened which file).

Thank you for your responses. It does seem that some kind of checking process is holding the file for a very short time. I tried the applications that you suggested, but I wasn't able to get the process Id (most of the time it showed INEXISTING PROCESS or the like).

That platform cleanup day (024) doesn't exactly "fix" the problem, it just bypasses it by using memory as the storing for input.

Anyway, just wanted to close the thread.