Ahhh...Still no better debugger with the new release :(

When will you guys stop treating the debugger in IDA like a second order citizen and make it more like OllyDBG or Syser debugger?

I think this should be the next priority.

Please tell me what you think. Thanks.

Well, it is already working, and I posted the following image a month (or two?) ago:

http://www.hexblog.com/ida_pro/pix/cpuview.gif

The biggest change is the user interface - is it that you meant by "more like other debuggers"?

If things go as planned, we will announce a beta soon.

That screenshot looks promising :)

Well, quickly like that off the top of my head:

-Ability to modify assembly code on the fly from whitin the disassembly window (Assemble)
+Of courses changes are not persisted to the disassembly and are done in memory only
+changes might be persisted in the IDA file and applied automatically next time the process is debugged (might be tricky)

-Memory dump with possibilty to edit data/advanced search/un-assemble data (and assemble) & memory pages

-Memory map of process and view of loaded modules

-Possibility to unassemble a loaded module on the fly from the debugger, or auto load an previously IDA unassembled module

-Clicking on a process/memory region takes you to the offset in process memory

-Show x64, MMX, SSE and SSE2 registers

-Possibility of debugging with the Hex-Rays decompiler output

-Configurable hotkey to bring momentarely the debugged application to the front (for conveniance in case the listing is covering it)

-Possibilty to edit registers directly...why the need for a popup? (at least make it an option)

...Just to name a few suggestions

Thanks for the list. Some of the items are already present in IDA (which just proves that it is huge and nobody can remember all its features ;), others are new. Alas, it is not ideas that we lack... We internally discuss very interesting ideas and have to postpone them again and again

I agree with Jason, the lack of ability to modify assembly code and memory is really a pain in the neck since sometimes it is necessary to "force" another code flow on the fly.