In large files (4700+ lines), the control of the scroll bar disappears, as you can see in the picture. Using up/down keys does not scroll either. This means that during debugging I cannot see what is happening (for some reason the debugger also does not focus on the current active line in these large files). Resizing does not help.

Do not remember I had this exactly problem with the new debugger but clearly it is still a work in progress. Hopefully Silverfrost is close to add all suggestions and fix all current complaints in the 64bit SDBG.

As kindly suggested by Robert (Silverfrost), you can modify the file %appdata%\sdbg64.ini You could just delete the file or edit the SourceWindow-H setting to be something sensible (like 40). This worked for me.

Also if looking for a text in a file, you can use Ctrl+S to do a search (case-sensitive). Ctrl+A repeats it.

I would like to learn about sdbg64.exe and sdbg64.ini and in this context I have a few questions.

1. I found a file sdbg.ini for the 32 bit debugger located in directory

C:\Users\<user name>\AppData\Local\VirtualStore\Windows

. However, there is no file sdbg64.ini in this directory and I was not able to create a file sdbg64.ini by means of sdbg64.exe. This might be related to the following observation:

When exiting sdbg.exe (32 bit), a dialog "Confirm exit" is displayed and I can put a check mark to the toggle button "Save size and position of open windows". When exiting sdbg64.exe the dialog "Confirm exit" is not displayed at all.

The version information of sdbg64.exe is

Silverfrost Debugger for 64-bit Windows version 8.10.3

2. The first line of sdbg.ini (32 bit) is

[Debugger-Win32]

. If I would like to create file sdbg64.ini manually, what would be the analogon to this line for the 64 bit debugger?

3. Where can I find information about the environment I can set for sdbg.exe (32 bit) and sdbg64.ini?

Looking how painfully slow goes development of SDBG64 I wonder if Silverfrost has the sources of 32bit SDBG or like with the Simpleplot they are missing? Why write the new debugger from scratch and observing its evolution going from primitive formless embrionic stages through the currently may be fish? Wasn't it better just to expand 32bit one on the new 64bit platform?

I don't know of the SDBG64 development, but I have had on-going projects where a major change gave me the excuse to start again and try to redefine the system approach and overcome all (or at least some of) those niggling problems that I thought were holding back the solution.
I have only had a few of those and the ones that worked for me keep me going and looking for the next big chance.

We'll have to wait and see if SDBG64 is one of these for Silverfrost, if the re-work is as much as you claim. To date, I have been impressed with the way FTN95 /64 has worked for my recent code development so I am hoping for the best.

SDBG64 has been ported from SDBG but this is not as quick and easy as may be supposed. Apart from obvious issues, the whole of the "backend" of FTN95 has been rewritten from scratch and this has a significant impact on the code for the debugger.

John, Aren't you one of those who almost never use debugger? Where are your bug reports and suggestions? How do you and such kind of programmers debug is mystery to me. But I know some people (C folks more often) who use their 7th sense for that and just happy with inserting gradfather's PRINT* between offending lines

Paul, then why GUI changed substantially to the total primitivity if it was ported? Saving settings, windows sizes and their states etc etc etc are not 64bit related. Any progress with the new release any time soon? May be all that is already fixed and I am barking on the empty tree. I ported some minor programs to 64bits but afraid to touch major code with the current debugger. One clueless Access Violation crash and I am out of luck for any further porting.

I am in the process of porting a big GUI application from 32 bit to 64 bit and I make use of sdbg64.exe quite often despite the lack of some GUI functionality. In most cases I use CTRL-F (find routine), CTRL-S (search text) and F2 for setting breakpoints. You may set a write breakpoint to variable via entering ALT-P to display a command window and then entering 'write_break xxx' to this command window. This helped in many cases.

Let me point out another aspect:
For my GUI port the availability of other utilities for building the executable (e.g. scc, or a library manager) is desirable and important, as well. And at this point you would discuss what is more important the GUI of sdgb64.exe or the 64 bit port of scc e.g..

Stripped down GUI was just first obvious problem of SDBG64. There were many others, mainly access violation crashes and still sometimes showing wrong offending line in the source. Me and Mecej4 wrote about these problems, and also made other soggestions. If you will find the bugs and have your suggestions do not hesitate to post here.

Had no time to look if new version from few days back fixed obvious deficiencies, not just the GUI.