VMWare 5.xx or higher can emulate x64-86 on 32-bit platform. More detailed information can be found on a site of the manufacturer http://www.vmware.com/

Hmm, I've been testing all my apps under QEMU for months now - from the very first version of MenuetOS IIRC. The sad thing is that QEMU is only 32-bit itself so 64-bit emulation is wacky, but lets hope they move to 64-bit native so they don't HAVE to emulate 64-bit under 32, but rather just pass 64-bit requests to 64-bit processor

2Feryno: Do you can to add display of abnormal float numbers (negative infinity etc.) in a window of FPU/MMX data more corect?
[edit]Remove url to screenshot[/edit]

Would it be possible to add the address of the access violation to the fdbg's message?

Something like

2 MazeGen, thank, I'll add it there.
After exception, Code 1st window is updated so you can see something after disassembled instruction - something between brackets -which is the address and then ? follows so it looks like [...address...]=? which means that fdbg failed to read memory at that address - but I'll add the address into the Log window too

2 Garthower - thank for idea, I was thinking about rewriting of the routines for displaying floating numbers in the time of your post. In fact of FPU instruction pointer and FPU data pointer method of detecting single steps in debugger I was made to rewrite these routines without usage of FPU instructions. I was thinking about one week long how to do it efficiently enough and finaly I got an idea which wastes 0,5 MB of memory but is quite accurate and perhaps fast enough too. If somebody is interested in FPU antidebugs then I'll post here more details.
It would be kind to test these new routines for displaying floating registers (st, mm, xmm) more thoroughly than my several minutes of limited testing...

edit from 2007 March 26: deleted attachment (quota limit)

I shall test work with floatint point numbers the nearest months very densely since now I develop the math-based RTL. At occurrence of new problems I shall inform certainly.

Floating point numbers are calculated with precision higher than necessary for any floating point numbers calculations, but they were simply truncated in previous version. Because Garthower is going to test floating numbers heavily, I added rounding for them. It's nicer to see e.g. 1.2000000 instead of 1.1999999 which was truncated 1.19999996301...

Hmmmm.... This rounding off is not absolutely exact with real values as I have understood? Can do is better roundings off how the program which is now debugged, it is established in corresponding operating registers? And that suddenly in the future because of it surprises will get out...

Every floating point number is calculated to more than 40 decimal digits by fdbg and it requires rounding at the end to fit into 18 digits for 80-bit FPU numbers, 16 digits for double precision, 8 digits for single precision.
In the feature it should be easily extended to show more digits of floating.
Most of floatings can't be stored absolutely accurate e.g. single precision 1.0e-40 could be e.g. 9.99999996512e-41 etc.
Rounding feature from ver. 0012 handles only these cases and doesn't decrease accuracy. You should allways keep in mind that there is something after the last shown digit of floating but it doesn't alter accuracy too much.

Thank to DLL produced by r22 I discovered a bug which happens only under Vista (not under older win versions) - fixed in ver 0013

deleted attachment, released new version

Hi Feryno!

I have a problem with FDBG. FDBG crashes at debugging this source code on command "xor rax,rax" (!!!)



with execption:
code=C0000005
addr=10000A484
rax=0
rbx=8
rcx=FF4
rdx=C0000018
rsp=225F3C0
rsi=0
rdi=225F3D0
r8=B
r9=77EC0000
r10=81
r11=206
r12=0
r13=0
r14=0
r15=0

Maybe, it's connected by that I have install today SP2?

mov qword [rax],0 -> mov qword [0],0
exception code C0000005 = access violation

so i don't find it strange that the program itself crashes, but does fdbg crash and close as well?

Yes, if to delete a command "mov qword ptr [rax],0", all works. But if it to return on a place, at me FDBG0013 crash itself before the command.

yeah, thank guys, it was serious bug when accessing unreachable memory
I tried to fix something to work under Vista in ver 0013 and I made another bug...
here fixed and stable version 0014
As Tommy wrote, debugger mustn't crash anytime.
If program being debugged (=debuggee) makes a bug, debugger must catch the buggy instruction and stay running. Debugger itself must be bug-free. Program being debugged (=debuggee) may contain bugs and debugger is responsible to discover them.

Now it's stable. Thanks Feryno for operative reaction to a problems!

VMware Workstation 5.5.x:

And that's logical, because VMware doesn't emulate a processor - it uses virtualization over a real processor and a regular x86 can't appear as an enhanced x86-64.

Bosch does support x86-64 over a regular x86. Apparently, so does QEMU, but I had troubles using it so far.

Are you no longer making a Linux64 version?

Linux version -
Perhaps new routines for parsing commands - at present time, commands are too much sensitive to improper parameters - e.g. if you type 2 spaces instead of 1 the whole command fails, this is the same scenario when you accidentally press CapsLock etc.
Perhaps creating multiprocess/multithread support (currently it handles only 1 process)?
Now I remember, I had really great idea, but it required completelly rearrangment of swithing to procedures of handling commands - the idea was: you can set what to do after every step - something like .gdbinit file
e.g. display 8 instructions, then xmm1-3 register etc. after every step - then you wouldn't need to type the same command every step.
And now I remember another idea - command line buffer holding old commands so you can press up/down arrow instead of typing long commands again.
But all this ideas require a lot of time which I currently don't have.

Hi, I've got this picture for you: http://www.tud.ttu.ee/~t060429/Up/Optimal.png (@1400x1050 res.)
Have you got any more optimal solutions for arranging sections?
One bad thing with this arrangement is that the Flags and Seg windows
are still too wide and Windows won't let me resize them any smaller

Btw, one small request:
-that under the Help menu > there could be About dialog with "Authoring message" and FDBG version.

Thank you!

Hello, Madis731

big guru on 64-bit asm with the nick r22 used to have screen resolution even 800x600
fdbg has a lot of MDI child windows, but usually only few of them are really necessary and most of them may be iconized to prevent overfilling your screen.
There is one strange fact - it is explained in the included help file - that there are more code and data windows...
The fact of 2 code windows doesn't mean 2-core CPU... Brief explanation - I used to debug with turbo debugger which had only 1 code window. When I needed to follow subprocedure (call) in code window then I lost the code at the instruction pointer so at the end I had to go back manually. So I thought that 2 code windows may help to somebody who needs it, others can simply iconize code 2nd windows to save a part of screen. Code 1st win keeps updated to RIP and code 2nd may be used for walking through other parts of code. This is the same with 3 data windows. For repz movsb it is good choice to have 2 extra data windows, and the first one is good for not to loosing the view into previous part of data. Usually, you need only 1 code, 1 data, 1 stack, 1 GPR, 1 RIP, 1 Flags, 1 XMM, 1 MM/ST and this configuration fits into 1024*768 screen resolution. If you need really big code window, you can stretch it up to 64 "lines" (ListView items = instructions) but then it occupies the most of your screen.

Seg windows are allmost completelly useless in ring 3 long mode (only 64-bit GS register seems to be usefull in some rare cases under 64-bit ms windows). Seg window is shown there only because of the existence of segment registers in long mode...
Windows doesn't let you to resize Flags and Segment registers windows because there is low limit of MDI child window size in OS.

Version of fdbg - this is the first and only one line in Log window when you run fdbg. The number there is strange (but logical) and it increases in every new version, it has the format yyyymmdd
(year,month,day).
Authoring message - if you mean the name of the author of fdbg - it is completelly useless. I remember how much helped me turbo debugger in DOS and win32 so fdbg is hopped to help others in win64 and linux64 too. If you use fdbg and it helps you, that is big reward for me, and putting author's name there would only waste space and produce bigger executable (btw. there has been an easter egg in fdbg for a long time - several versions backward - since the begin of year 2007), and perhaps nobody has discovered it yet - the compression ratio... I like small files as every asm coder).

I think (perhaps only my private personal opinion) that the most valuable part of fdbg is disasm engine. Everything other there is OS specific. If somebody needs to write noncommercial debugger for another OS, then he/she may freely use fdbg disasm engine and write only OS specific part of the new debugger.

P.S. a bit off topic, only small note after seeing you picture more detailed:
code 2nd
401000 sub rsp,10
401004 mov rcx,0
40100B call qword [00000000004030C4] -> it seems API

1.
the rip is not aligned 16 at the time of calling API (Vista is extremely sensitive to it...)
401000 sub rsp,18 ; should be better (other choice: push rax, sub rsp,10)

2. mov rcx,0
you can use amd64 zero 64-bit extending of 32-bit operation and thus save 1 byte of REX prefix
401004 mov ecx,0 does the same
401004 xor ecx,ecx is the smallest solution - only 2 bytes instead of 6 bytes of mov rcx,0

You will find a lot of possibilities how to shrink any code if you look into it with debugger.

code 1st
40169B mov esi,[00000000004034F8] ; []=004035F0 ; good, it seems low dword of 64-bit memory pointer
...
sub esi,... ; may destroy (zeroing) upper dword of rsi
...
repz movsq
very dangerous combination before repz movsd - but you are sure that esi points into low dword of 64-bit memory pointer. If any data is above 0000000100000000 then you will cause exception.
mov rsi,...
sub rsi,...
repz movsq
sounds safer (but a bit bigger because of REX prefix - rsi instead of esi)

ufff, a bit looooong reply, OK, I'm ending... just joking

1. Yeah, but I'm on 2003 Server and it doesn't give any errors. Btw, the code behind it is:
start:
invoke GetModuleHandle,0
2. But making it optimal would handicap the readability:
start:
xor ecx,ecx
invoke GetModuleHandle
hmm...

sub esi means that I only use DWORDs in the memory and if it wraps over, its needed

Btw, that was some random test-code that I will scrap anyways I'll post the resulting final code in the Project & Ideas section. There are the very clever algoritms there (some school projects).