Open Korporal opened 7 years ago
sharwell
commented
7 years ago 💠Would be interesting if the Navigate To feature had a provider that looked for information in PDBs. Not sure how it would work for cases where symbols aren't loaded though.
Korporal
commented
7 years ago @sharwell - Years ago I worked a great deal and in great depth, on VOS an OS developed by Stratus for (initially) 68020 based hardware fault tolerant minicomputers. VOS was "developed" from Multics by people who had worked on Multics in the 70s.
Like Multics it was written mostly in PL/I (a superb language in its day) in fact Multics was the first OS written in a high level language. Anyway the OS was all text/command line (dumb terminals) and the debugger was rather powerful, innovative really.
I can't recall details but you could run any executable by either typing its name:
Once in debug "mode" one there were commands that were designed to let you know what source files were used, whether they'd been changed since the executable was built and so on.
You could therefore "list" these and then use a command: "source
I miss this and for years I've grumbled that Visual Studio debug only loads source files as and when the execution path forces it to.
We should really be able to do the same as VOS debug and be able to "list" all source files that the system can discern as accessible, or show a view similar to a decompiler with namespaces, classes, methods etc.
It could even be a new Tool Window with a tree view, first nodes for each assembly, then when expanded all of the source files that were used to build that assembly. Then we could simply select (click) the file we want and see it and set breakpoints ahead of running the code.
Today if you (say) attach the debugger to an OS Service and interrupt it, you'll be able to see that stack (for whatever thread it happens to be) and step up/down the stack. But there's no easy way to deal with stuff like "I want to put a break inside that loop that's in a method named ProcessQueue or was it in a file we named AnalayzeQueuecs...?".
If MS were to offer me a job I'd even design and write it myself !
PS: VOS had other impressive features, oddly never apparently considered for Windows NT. For example all files on NT are pretty much "stream"files, a sequence of bytes with some awareness of line based files.
VOS had this plus other forms of files:
Indexes - you could easily create named indexes on files, the index had:
This is based on (rusty) memory. But you could have a string index that's comprised of byte 0 thru 3 followed by bytes 24 thru 27 (8 bytes) for example (seen by the "user" as an 8 char string, yet actually composed of 4 bytes from one part of record followed by 4 bytes from another part of record).
NTFS (with streams) technically can support this capability, yet to this day all files on Windows are just dumb streams of bytes, that is they have no organizational metadata other than "I am just a long sequence of bytes".
Consider providing a means in Visual Studio when debugging to easily navigate to a source file associated with the debugged app.
Often when we debug we do not know exactly where the source files are for the code we want to put breakpoints in, this can happen when debugging into some external assembly or when we attach to a running process.
But if the PDB is around then the debugger could list the source files for each assembly in some tool window and the developer could then just select a file to have it open in Visual Studio.
Currently when debugging, if I want to put a breakpoint in some code that's in a file not yet loaded in the IDE I must use File Open and manually navigate to the file, assuming I even know where the right version is.