TRIM would do the same thing in Windows as it does in every other operating system. It's a command to the SSD (or other device that supports it), mostly just passed through as is by the operating system.
First, there are two properties of flash that are important here:
- Reading and writing flash is fast, but erasing is slow.
- A given block can only be erased a certain number of times before it wears out.
This is very different from magnetic media: magnetic media has no such concept as erasing (writing effectively erases what was there before), and it doesn't matter how many times you overwrite the same block (in fact, rewriting a block, if it has any detectable effect at all, is a good thing because it restrengthens the magnetic field).
The best way to use flash is using a filesystem like jffs2 or ubifs that is designed for it, takes advantage of the fact that flash can be written incrementally (though not erased incrementally) and performs wear levelling across the device (attempts to erase each block an approximately equal number of times).
But SSDs, SD cards, USB sticks, and most every other kind of flash block device doesn't let you use these flash-specific filesystems properly because there is what's called a flash translation layer in between the raw flash and the block device interface. This layer cannot be bypassed and emulates a traditional (magnetic) block device on top of the flash. It implements the necessary wear levelling by scattering virtual blocks of the emulated block device over different physical locations in a way that varies each time a block is rewritten. It also lets the virtual block device has a small block size that resembles the block size of traditional block devices (something like 512 bytes or 4096 bytes) even though the size of a physical flash erase block is much larger (usually 128KBytes).
In the simplest case, the FTL (flash translation layer) has to do the following work every time you write a block on the virtual block device, assuming a flash erase block size of 128KB and a virtual block size of 4KB:
- Read one whole physical block (which contains 32 virtual blocks)
- Replace the one you're writing with new contents and keep the other 31 as is
- Erase a new flash block somewhere on the device (or take one that's already been erased recently)
- Write this new set of 32 virtual blocks on it.
Real FTLs do a lot of smart optimizations in order to avoid having to frequently do this full-blown process, so it's not quite as bad as that makes it sound. But regardless, the FTL's job will sometime involve rewriting new copies of unrelated blocks when some other block is written.
The trouble is that this is sometimes wasted work! The FTL doesn't know which blocks are in use and which blocks are free. That's the job of the filesystem that sits on top of the virtual block device. There is no need to rewrite copies of blocks that are actually free, because nobody will care if the contents of those blocks change during the process of one of the FTL's remapping and rewriting operations. If only there was a way for the FTL to be told which virtual blocks it doesn't have to care about preserving. Well, that way exists, and it's called TRIM. TRIM will save your flash by allowing the FTL to erase and rewrite blocks less often.
Now, with this background, on to your question: how does recovery on SSD work?
Well, the filesystem that sits above the FTL shouldn't be TRIMing any blocks that it actually still needs access to, so I don't really see the relevance of the question. If the filesystem has bugs in it, then, well, recovery will mostly depend on how bad the bug it, I guess. But there's no question that, with or without TRIM, the added complexity of the FTL layer will most certainly make recovery of corruption more difficult under some cimcumstances, for example if the FTL's virtual-to-physical mapping information gets corrupt.