The approach in my answer isn't one I would necessarily recommend, as it is basically a huge hack. However, it is possible to 'host' pretty much any Windows application inside another. Caveats:
- This is a big fat hack
- I'm not sure at all how well it plays with the various security features that are e.g. in Vista
- You'll be working with low-level and sometimes underdocumented APIs the whole time, and doing things that are not what the original designers anticipated.
- I don't know the various APIs well enough to tell you exactly what to do, so this is a very rough sketch...
The basic approach would be to:
- Start up a new explorer.exe process
- Get its HWnd
- Using p/invoke calls into various windows APIs (mostly shell32.dll), re-parent it into a NativeWindow or UserControl of your own.
- You can then replace its WndProc message handler with your own, subclassing it to inject your own application-specific behaviors. (C++ example; stackoverflow question WRT calling the old/default WndProc; googling will produce a lot of answers. I've done this before in C# and (ick) VBA) This will let you replace various UI behaviors with your own, albiet at a very low level. (It's dependent on how exactly explorer is implemented: higher-level things like menu clicks can get their own message and so be easier to handle; but other aspects of explorer's behavior you might only get the raw mouse messages.)
You'll want Spy++ in order to figure out what messages happen when.
Yes, this is a great way to build lots of very ugly and fragile code, but it's (a) sometimes the only way to get things working right; and (b) great for learning what's going on under the hood of Windows.Forms / MFC / etc.