• mgrier's WebLog

    Canonical Function Structure

    • 5 Comments
    Here is a proposed canonical structure for functions/procedures. Clearly in some cases some sections would not be present. What’s important is to understand the basic phasing of the work to be done and the separation of tasks. int foo( char ...
  • mgrier's WebLog

    The NT DLL Loader: FreeLibrary()

    • 6 Comments
    Let's review the loader's modus operandi and derive the (once again simple!) rules for what the heck is going on. When someone calls FreeLibrary(hInstance), the loader walks the closure of the dependencies for the module/instance in question and if...
  • mgrier's WebLog

    The NT DLL Loader: DLL_PROCESS_ATTACH reentrancy - wrap up

    • 2 Comments
    Hopefully the culmination of these cautionary tales is clear: you're walking a very fine line when you attempt to reenter the loader from within a loader callout. You're (more!) subject to ordering and cycle issues, you can force initialization to proceed...
  • mgrier's WebLog

    The NT DLL Loader: DLL_PROCESS_ATTACH reentrancy - step 4 - ramifications of questionable quality

    • 1 Comments
    Last time I alluded to the world of hurt you're in when the loader is reentered during DLL_PROCESS_ATTACH and the initialization of another DLL failed. The state of the affairs is pretty derivable from the clues that I've left behind in the series...
  • mgrier's WebLog

    The NT DLL Loader: DLL_PROCESS_ATTACH reentrancy - step 3 - quality requirements

    • 8 Comments
    Now we're loaded for bear! We understand how PEs which are either launched via CreateProcess() or loaded via LoadLibrary() are the roots of directed cyclic graphs. Each new graph is turned into a linear initialization-order list where nodes further from...
  • mgrier's WebLog

    The NT DLL Loader: DLL_PROCESS_ATTACH reentrancy - step 2 - GetProcAddress()

    • 3 Comments
    Last time we pondered what does LoadLibrary() do when called inside of a DLL_PROCESS_ATTACH callout. The answer was pretty simple and predictable - the only nuance is that the initializers are not run before returning. Now place yourself in the position...
  • mgrier's WebLog

    The NT DLL Loader: DLL_PROCESS_ATTACH reentrancy - step 1 - LoadLibrary()

    • 7 Comments
    So what happens if you call back into the loader when you're inside a loader callout (DllMain) for DLL_PROCESS_ATTACH? I'll be addressing teardown (DLL_PROCESS_DETACH) after completing the DLL_PROCESS_ATTACH series. The first issue is: what about...
  • mgrier's WebLog

    The NT DLL Loader: reentrancy - play along at home!

    • 12 Comments
    Anyone care to hazard a guess about what happens if you have the following code in your DllMain()? Ignore the leak and the lack of error checking; focus on the what the loader's behavior has to be... BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD fdwReason...
  • mgrier's WebLog

    The NT DLL Loader: DLL callouts (DllMain) - DLL_PROCESS_ATTACH deadlocks

    • 14 Comments
    The Windows DLL loader (I wasn't around then but I assume some of this even comes from the days of 16-bit Windows) has a feature where a DLL may have an "entry point". If a DLL has an entry point, the loader calls into it on certain significant events...
  • mgrier's WebLog

    The NT DLL loader: dynamic unloads

    • 5 Comments
    To recap our story from last time: The NT DLL loader starts from some PE (either the main EXE or the DLL which is passed in to the LoadLibrary() API), walks the graph of static imports rooted with that first PE. You can think of the loader as then...
  • mgrier's WebLog

    The NT DLL Loader: basic operation

    • 6 Comments
    Let's start simply and consider the mythical vertical application (a topic itself for another day). I'm not going to walk through what a PE is or a DLL or an EXE; if you don't know, follow the link or take a gander around MSDN. Let's call it ccalc...
  • mgrier's WebLog

    How the NT Loader works

    • 12 Comments
    My team maintained the NT loader (the component that loads DLLs) for about a year or so during Windows XP as we were adding the isolated application features to it so we got quite an interesting perspective on this lovely little piece of technology. Warning...
  • mgrier's WebLog

    Enough about in-memory models and transactions for now

    • 2 Comments
    I want to follow up on this topic of transactional behavior in memory but to motivate it I'm going to have to further discuss my other topics more about invariant restoration and (eventually) failure handling. The main point is this: there are potentially...
  • mgrier's WebLog

    Transactions and in-memory data (part 3 of n)

    • 2 Comments
    Last time I laid out a little framework for transactional rollback. It clearly is not sufficient for a real honest-to-goodness persistent transaction but if you can tolerate every ESE failing (due to allocating the rollback log entry) it's pretty compelling...
  • mgrier's WebLog

    Transactions and in-memory data (part 2 of n)

    • 6 Comments
    Buffering the opertations wasn't particularly successful. Let's look at maintaining a rollback log. Seems pretty simple. You can do something like: typedef void (*rollback_function_ptr_t)(void *context); typedef struct _rollback_record { rollback_function_ptr_t...
  • mgrier's WebLog

    Transactions and in-memory data (part 1 of n)

    • 1 Comments
    [Maybe I'll fill in the "n" when I'm done. I haven't had time to plan out the entire series...] In yesterday's post, I covered basically two approaches towards how to achieve transactionality. One is to build up a log of what to do when the commit...
  • mgrier's WebLog

    No Chinese Dictionaries

    • 3 Comments
    I want to go on the record and note that I will not be deveoping a Chinese/English Dictionary, in unmanaged code , managed code or any code (pages) .
  • mgrier's WebLog

    More than one way to skin a (transactional) cat

    • 4 Comments
    Let's briefly look at how databases deal with transaction rollback. I'm going to ignore a lot of other fun stuff around locking protocols, snapshots, isolation etc. and only focus on how atomicity & durability are achieved. I'll keep the conversation...
  • mgrier's WebLog

    Implementation patterns to support transactional functions

    • 1 Comments
    Let's go back now to why I had a hard time with using the STL std::map pattern. It was because for the primary failure-prone access pattern (insert), there is an inverse operation which could not fail. A common pattern in TxFn (sorry I can't keep writing...
  • mgrier's WebLog

    Local vs. global analysis revisited

    • 1 Comments
    I posted that last item before having my coffee so it's really not suprising that I forgot to get around to my point. My point is this: there are abundant tools (including the human brain) which are good at local analysis. Global analysis is hard;...
  • mgrier's WebLog

    Whole program vs. local analysis

    • 7 Comments
    A quick note for today. Maybe more tonight. Internally at Microsoft, as you can imagine, we have a number of tools to assist building our software. Many are internal-only; contrary to the black-helicopter gang out there, there is a lot of cost to shipping...
  • mgrier's WebLog

    Working with inexact error contracts

    • 1 Comments
    Last time I lamented that the fact that std::map::erase() is not permitted to fail made it hard to come up with an example. But the vector pattern has the basic problem I wanted to discuss. First I'll write the obviously correct C code and then we...
  • mgrier's WebLog

    Even good design can't succeed in isolation

    • 1 Comments
    I tried three times to write yesterday's entry which was intended to explore the same problems with trying to restore invariants in failure paths. Instead I kept getting fouled up because the collections I was using were based on the STL design. The STL...
  • mgrier's WebLog

    Why is fclose()'s contract so confusing?

    • 5 Comments
    Because it’s a long established pattern and contract, let’s explore fclose() today. Here’s my ideal fclose() implementation: int fclose(FILE *fp) { close(fp->fd); free(fp); return 0; } But of course close() can fail . Yuck. I found this man...
  • mgrier's WebLog

    What if close could fail?

    • 4 Comments
    Yesterday I made the claim that close() can’t fail in a meaningful way. Meaning that if it’s invoked on an object in a state that does not support close(), it’s a programming/coding error. I believe that this is correct but we’ll see that there are...
Page 1 of 2 (36 items) 12