Hi, thanks for the patch. A few questions,

• There seems to be some whitespace mix-up in your patch, making the diff a bit messy. If it's not too much trouble, please convert space indentation to tabs per the project's .editorconfig, and rebase.
• There is some currently-unused code in src\profiler\debugger.cpp, do you think it could be useful?
• As I understand, there is no option to use the old process starting method. Do you think there can be any disadvantages to always using the debugger API? For example, DLLs that are dynamically loaded very soon after startup, or delay-loaded DLLs?
• Can this be used to profile new threads as they are created (issue New threads created during profiling get ignored #4)?

There seems to be some whitespace mix-up in your patch[...]

Yes. I stopped using tabs a few years back. Can convert and resubmit.

There is some currently-unused code [...] do you think it could be useful?

Most are there for completeness, but some will be useful. Didn't want to be cull prematurely.

As I understand, there is no option to use the old process starting method[...]

The old method could still be used as a fall-back method.

Do you think there can be any disadvantages to using the debugger API?[...]

Unfortunately, attaching at any time can miss some delay-loaded DLLs, late-start threads etc. So the same disadvantages apply for any method that doesn't get notifications on these events. But debugging API offer a solution.

Can this be used to profile new threads as they are created (issue #4)?

Correct. And it should. A debugger is notified of all major events including thread start/end and DLL loading/unloading. I'd like to see these added and used to their full extent, and had them in mind when I added the code above.

Most are there for completeness, but some will be useful. Didn't want to be cull prematurely.

Sorry, to clarify: There already exists some similar but unused code in the Very Sleepy codebase in the file "src\profiler\debugger.cpp".

The old method could still be used as a fall-back method.

Would it make sense to expose this as a setting the user can toggle?

Sorry, to clarify: There already exists some similar but unused code in the Very Sleepy codebase in the file "src\profiler\debugger.cpp".

My bad. Hadn't noticed this code (I wasn't even expecting it). I guess merging is in order.

Would it make sense to expose this as a setting the user can toggle?

Yes. That'd be ideal.

Perhaps it'd be best if I split this PR. First the 64-bit process detection code and misc changes can go in, then the debugging code (merged) then user option to control the hooking method. Thoughts?

Perhaps it'd be best if I split this PR. First the 64-bit process detection code and misc changes can go in, then the debugging code (merged) then user option to control the hooking method. Thoughts?

I do not have a preference, so feel free to do as you find more comfortable.

I'll close this PR and open another. Thanks.