Unpack, Packer or Compiler?

It's long time for me to think about how can we unpack/unprotect apps.
Normally, we unpack it with unpacker, debugger and so on. It means packer dependent. With packer update, we have to update our unpacker.
What I think about is compiler-dependent unpacker. If we can develop a tool to unpacking apps packed by different packer/protector , only if compiled with the same compiler. An app is VC6++ compiled, it maybe packed with aspack, or upx, or protected with aspr and so on, we have a tool to unpack it because of it's vc6++ compiler, avoiding its packer. As a native win32 GUI program, it's compiler is mostly vc6++, delphi, bcb, vb, asm. I found compiler such as MFC, delphi, vb, has their unique structure in compiled EXE/dll file. It is combinded with function modules.

2 years ago, An OEP finding tool in woodmann forum used compiler-dependent technology. Dede, a delphi disassembler is the same tech, MFC structure recognition also OK.

Altough, more and more protector use pre-dips tech, but I didn't found it dealing with the function module pointer ---- the skeleon of function modules. So I think it maybe workable to do compiler-dependent unpacker.