rbmm
Joined 2 years ago
Joined 2 years ago
I am a low-level Windows developer with extensive knowledge of Windows internals, Win32/NT APIs, debugging, research, etc., and—most importantly—expertise in the Windows logon area, credential providers, and related technologies.
Remote: yes
Willing to relocate: no
Technologies: windows low level development, windows internals, win32/NT api, debugging, research, DLLs, Processes, and Threads, IPC, asynchronous I/O, tokens, SD, crypto api, certificats, authentication( credential providers, authentication packages, etc), tpm, WDM, hooking, ..own debugger and tools, some PKI-based windows logon solutions
Resume/CV:
https://stackoverflow.com/users/6401656/rbmm ( https://stackoverflow.com/tags/winapi/topusers - #8 All Time )
https://www.youtube.com/@alexshort1643/videos
Email:[email protected]
Thanks for the comments.
The second part was strictly personal. I’m wondering if there’s any way to get in touch with the team handling this position—bypassing the standard process. I say this because I genuinely possess unique knowledge and experience in the key required areas (low-level Windows development, credential providers, debugging all of that) and had some public proof of this—like my Stack Overflow ranking, for instance, which—unlike a résumé—can't be faked (and can look up "rbmm windows"). but, I can't even apply for the position or make myself known. So, I was asking if anyone happens to know people there (despite slim the extremally low, i nothing have to lost).
Thanks for the whoishiring link. My expertise is in a very narrow, specialized field. There are incredibly few job openings that actually suit me (I don't just "apply" (not in direct sense) for everything; I only target roles where I truly have specialized knowledge and experience). There are literally only a handful of them. However, it has now become absolutely impossible to reach them (following the loss of LinkedIn)—though I suspect there are very few people with deep expertise in such fields too.
also look my 2 comments on reddit: https://www.reddit.com/r/cpp/comments/1b55686/comment/ktfhjs... and https://www.reddit.com/r/cpp/comments/1b55686/comment/ktfggu...
if say true - i here in very strange position. i am by self under debugger research exacly what happens in concrete case and create repro code. i think that implementation of the RtlReleaseSRWLockExclusive is not the best and may be really containing "bug" as i in more details describe in comment on reddit. but from another side, if you want pure formal c++ rules - can you explain - in what exactly was bug in concre case ? what rule/guarantee is violated ? why demo code decide that ALL shared waiters can at once acquire the lock. formal documentation not state this. this intuitive must be true, because no exclusive request more. but.. i really dont know. and i also for fun create own implementation of SRW lock ( if someone interested to look -https://github.com/rbmm/PushLock ) which free from this roblem - i always ( hope) do only single atomic change to lock state during api call. and finally - sorry for my english and too long answer
allow but NOT DEMAND this. If one thread has acquired the shared lock , other thread can acquire the shared lock too. but only CAN. in some case system not let another thread enter to lock, despite it also request share access. one case: if another rthread request exclusive acess - he begin wait and after this - any thread which acquire even shared access to lock - also begin wait
If lock_shared is called by a thread that already owns the mutex in any mode (exclusive or shared), the behavior is undefined.
and
Shared mode SRW locks should not be acquired recursively as this can lead to deadlocks when combined with exclusive acquisition.
why is this ? because if between 2 calls to lock_shared ( AcquireSRWLockShared ) another thread call AcquireSRWLockExclusive - the second call is block.
the code in example make assumption that ALL threads can enter to lock at once. that if one thread enter to lock in shared mode, another thread also ALWAYS can enter to lock in shared mode (if no exclusive requests). but i not view clear formalization of such requirement. and we must not based on this.
i be will add next rule:
thread inside lock must not wait on another thread to enter this lock
this is obvivius for exlusive access, but not obvivous to shared. but must be cleare stated along with the recursive rule ( should not be acquired recursively as this can lead to deadlocks, even in shared mode)