softICE had interesting technology,ut manually freeze system and drawing a window over whatever currently displayed on screen.
how softICE internally manage it’s window??
can we drawing window using device driver??
The short answer is no ? drivers do not create or manage windows.
The long answer starts with, yes, as code running in KM a driver can do anything including many things that are not supported and will certainly crash the system.
In the case of softice, IIRC as stop the world debugger, it did not create a ?window? in the sense of a Windows GDI window, but rather pounded directly on the video hardware behind the back of whatever video driver was running. This obviously dangerous technique was deemed appropriate for a debugger designed to run on the system being debugged. The advent of simple virtualization has obsoleted the motivation for such a technology IMHO
Sent from Mailhttps: for Windows 10
From: xxxxx@gmail.commailto:xxxxx
Sent: January 7, 2017 12:23 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: [ntdev] how softICE gui works?
softICE had interesting technology,ut manually freeze system and drawing a window over whatever currently displayed on screen.
how softICE internally manage it’s window??
can we drawing window using device driver??
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></mailto:xxxxx></mailto:xxxxx></https:>
On Jan 7, 2017, at 8:11 PM, Marion Bond > wrote:
In the case of softice, IIRC as stop the world debugger, it did not create a ‘window’ in the sense of a Windows GDI window, but rather pounded directly on the video hardware behind the back of whatever video driver was running.
You recall correctly. SoftICE only worked in one-screen mode on certain graphics cards – cards where they had their own internal drivers. They would essentially snapshot the frame buffer, then do their own drawing, by pounding directly into the kernel mapping of the frame buffer.
Later, they could do any board that supported DirectDraw, again by grabbing a pointer to the primary surface and drawing directly.
I was writing display drivers at the time, where this technique was not particularly useful. We kept a monochrome graphics card around for years, just so we could run SoftICE on the mono monitor.
—
Tim Roberts, xxxxx@probo.commailto:xxxxx
Providenza & Boekelheide, Inc.</mailto:xxxxx>
I miss SoftIce. I cut my teeth with SoftIce on DOS, and used it all the way
through XP. I cried when it was discontinued. An Asian vendor tried to
create a replacement, but it was junk. In my setups, I always added a
secondary monochrome video adapter to my system, and directed SoftIce to
use the monochrome display as the debug terminal. Because the old VGA and
Mono adapters mapped memory to b8000, and b0000 respectively (color or
mono), it was easy for SoftIce to simply change modes, and write directly
to the video memory. This made it extremely responsive and fast.
On Sun, Jan 8, 2017 at 3:19 AM Tim Roberts wrote:
> On Jan 7, 2017, at 8:11 PM, Marion Bond wrote:
>
>
> In the case of softice, IIRC as stop the world debugger, it did not create
> a ‘window’ in the sense of a Windows GDI window, but rather pounded
> directly on the video hardware behind the back of whatever video driver was
> running.
>
>
> You recall correctly. SoftICE only worked in one-screen mode on certain
> graphics cards – cards where they had their own internal drivers. They
> would essentially snapshot the frame buffer, then do their own drawing, by
> pounding directly into the kernel mapping of the frame buffer.
>
> Later, they could do any board that supported DirectDraw, again by
> grabbing a pointer to the primary surface and drawing directly.
>
> I was writing display drivers at the time, where this technique was not
> particularly useful. We kept a monochrome graphics card around for years,
> just so we could run SoftICE on the mono monitor.
> —
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:>
Jamey Kirby wrote:
I miss SoftIce. I cut my teeth with SoftIce on DOS, and used it all
the way through XP. I cried when it was discontinued. An Asian vendor
tried to create a replacement, but it was junk. In my setups, I always
added a secondary monochrome video adapter to my system, and directed
SoftIce to use the monochrome display as the debug terminal. Because
the old VGA and Mono adapters mapped memory to b8000, and b0000
respectively (color or mono), it was easy for SoftIce to simply change
modes, and write directly to the video memory. This made it extremely
responsive and fast.
The biggest advantage of SoftICE was discoverability. As you typed a
letter, it showed you the commands that started with that letter. This
often resulted in “hey, what does THAT do?” moments that led to revelations.
WinDBG commands, on the other hand, look like RS232 line noise. I am
absolutely boggled by some of the pseudo-random character streams that
come up in our discussions here. It’s even worse than Perl, and that’s
saying something. Now, I clearly understand that it is weighed down by
the terrible burden of a 30-year legacy, but I also miss the SoftICE UI
concept.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I miss the speed of softice. It takes windbg ages to single step. With softice I could tap the step key a half dozen times and it would be there before my finger was up. Windbg will throw some the of the keystrokes in the garbage and take ages to do a single step even on fast connection hardware like 1394 and ethernet. Our company charged clients 3x more if they required windbg in those days because the productivity difference was so terrible.
That’s different than my experience of windbg. If I connect the debugger and target machine over 800 Mbs 1394, with an LSI card that knows how to RDMA above 4GB, if you press and hold the single step key it single steps at keyboard repeat speed, which is 20-30 steps/sec. If you’re not seeing this performance, then perhaps your 1394 connection is not working optimally. Unfortunately, the LSI 1394 chipset is fading away, although last I checked cards still were available in the retail sales pipeline. I don’t believe any of the other 1394 chips implemented the optional high memory limit register, like the LSI chip did.
Jan
On 1/9/17, 4:31 PM, “xxxxx@lists.osr.com on behalf of xxxxx@gmail.com” wrote:
I miss the speed of softice. It takes windbg ages to single step. With softice I could tap the step key a half dozen times and it would be there before my finger was up. Windbg will throw some the of the keystrokes in the garbage and take ages to do a single step even on fast connection hardware like 1394 and ethernet. Our company charged clients 3x more if they required windbg in those days because the productivity difference was so terrible.
We tracked down the “right” 1394b cards and sell them in the store:
https://store.osr.com/product/1394-card-for-debugging-pcie/
These cards rock (my experience matches Jan’s).
-scott
OSR
@OSRDrivers
“Jan Bottorff” wrote in message news:xxxxx@ntdev…
That’s different than my experience of windbg. If I connect the debugger and
target machine over 800 Mbs 1394, with an LSI card that knows how to RDMA
above 4GB, if you press and hold the single step key it single steps at
keyboard repeat speed, which is 20-30 steps/sec. If you’re not seeing this
performance, then perhaps your 1394 connection is not working optimally.
Unfortunately, the LSI 1394 chipset is fading away, although last I checked
cards still were available in the retail sales pipeline. I don’t believe any
of the other 1394 chips implemented the optional high memory limit register,
like the LSI chip did.
Jan
On 1/9/17, 4:31 PM, “xxxxx@lists.osr.com on behalf of
xxxxx@gmail.com” xxxxx@gmail.com> wrote:
I miss the speed of softice. It takes windbg ages to single step. With
softice I could tap the step key a half dozen times and it would be there
before my finger was up. Windbg will throw some the of the keystrokes in the
garbage and take ages to do a single step even on fast connection hardware
like 1394 and ethernet. Our company charged clients 3x more if they required
windbg in those days because the productivity difference was so terrible.
I miss softice like I miss win98.
Mark Roddy
On Tue, Jan 10, 2017 at 10:22 AM, Scott Noone wrote:
> We tracked down the “right” 1394b cards and sell them in the store:
>
> https://store.osr.com/product/1394-card-for-debugging-pcie/
>
> These cards rock (my experience matches Jan’s).
>
> -scott
> OSR
> @OSRDrivers
>
> “Jan Bottorff” wrote in message news:xxxxx@ntdev…
>
>
> That’s different than my experience of windbg. If I connect the debugger
> and target machine over 800 Mbs 1394, with an LSI card that knows how to
> RDMA above 4GB, if you press and hold the single step key it single steps
> at keyboard repeat speed, which is 20-30 steps/sec. If you’re not seeing
> this performance, then perhaps your 1394 connection is not working
> optimally. Unfortunately, the LSI 1394 chipset is fading away, although
> last I checked cards still were available in the retail sales pipeline. I
> don’t believe any of the other 1394 chips implemented the optional high
> memory limit register, like the LSI chip did.
>
> Jan
>
>
> On 1/9/17, 4:31 PM, “xxxxx@lists.osr.com on behalf of
> xxxxx@gmail.com” > xxxxx@gmail.com> wrote:
>
> I miss the speed of softice. It takes windbg ages to single step. With
> softice I could tap the step key a half dozen times and it would be there
> before my finger was up. Windbg will throw some the of the keystrokes in
> the garbage and take ages to do a single step even on fast connection
> hardware like 1394 and ethernet. Our company charged clients 3x more if
> they required windbg in those days because the productivity difference was
> so terrible.
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> lists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:></http:>
I couldn?t agree more about poor interface design
IMHO power shell is worse ? at least most windbg commands are short ? but nothing is worse than the fixation with ribbon based ui
Sent from Mailhttps: for Windows 10
From: Tim Robertsmailto:xxxxx
Sent: January 9, 2017 2:24 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: Re: [ntdev] how softICE gui works?
Jamey Kirby wrote:
> I miss SoftIce. I cut my teeth with SoftIce on DOS, and used it all
> the way through XP. I cried when it was discontinued. An Asian vendor
> tried to create a replacement, but it was junk. In my setups, I always
> added a secondary monochrome video adapter to my system, and directed
> SoftIce to use the monochrome display as the debug terminal. Because
> the old VGA and Mono adapters mapped memory to b8000, and b0000
> respectively (color or mono), it was easy for SoftIce to simply change
> modes, and write directly to the video memory. This made it extremely
> responsive and fast.
The biggest advantage of SoftICE was discoverability. As you typed a
letter, it showed you the commands that started with that letter. This
often resulted in “hey, what does THAT do?” moments that led to revelations.
WinDBG commands, on the other hand, look like RS232 line noise. I am
absolutely boggled by some of the pseudo-random character streams that
come up in our discussions here. It’s even worse than Perl, and that’s
saying something. Now, I clearly understand that it is weighed down by
the terrible burden of a 30-year legacy, but I also miss the SoftICE UI
concept.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></mailto:xxxxx></mailto:xxxxx></https:>
On Jan 10, 2017, at 2:36 PM, Mark Roddy wrote:
>
> I miss softice like I miss win98.
I don’t know what that means. You do or you don’t? Win 98SE was, in my opinion, the pinnacle of the 16-bit Windows systems. It was solid and reliable.
—
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
On Jan 10, 2017, at 3:17 PM, Marion Bond > wrote:
I couldn’t agree more about poor interface design
IMHO power shell is worse – at least most windbg commands are short – but nothing is worse than the fixation with ribbon based ui
PowerShell doesn’t imply a UI, but I have to step up to say a good word about PowerShell. It, at least, has the great benefit of discoverability. Because they have used rational and predictable rules to form their commands and stuck to it, you can make a pretty good guess as to PowerShell commands even if you don’t know them. That takes discipline, but it pays back in the long term. CDC used the exact same philosophy in their NOS/VE mainframe system.
—
Tim Roberts, xxxxx@probo.commailto:xxxxx
Providenza & Boekelheide, Inc.</mailto:xxxxx>
Yes win98 was pretty good, but would you really like to be using it today?
Do you actually “miss it”? It would completely suck for a huge number of
reasons. Lots of things that are now pretty horrible were once “the
pinnacle”.
SoftIce solved a problem that existed for a rather brief period of time,
its approach to system debugging is now useless.
Mark Roddy
On Wed, Jan 11, 2017 at 2:28 AM, Tim Roberts wrote:
> On Jan 10, 2017, at 2:36 PM, Mark Roddy wrote:
> >
> > I miss softice like I miss win98.
>
> I don’t know what that means. You do or you don’t? Win 98SE was, in my
> opinion, the pinnacle of the 16-bit Windows systems. It was solid and
> reliable.
> —
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:></http:>
Agree.
I miss SoftICE and Win98 both about as much as I miss my last stomach virus.
SoftICE was always a hack from hell. It was horrifically invasive, full of hooks and digging into random OS data structures at random offsets. I get that people liked it because it was fast and allowed single system debugging. I never warmed to it, personally. Compared to WinDbg, even back then, SoftICE always felt old and out-of-date to me.
As I remember them, the good old days mostly weren’t so good.
Peter
OSR
@OSRDrivers
+1
The thing I most hated about SoftIce was if you were developing a highly
threaded environment, you were going to find things worked differently
without SoftIce. I don’t just mean debugger versus no debugger, but really
differently, the hacks in SoftIce as part of its hooks really changed what
was concurrent.
Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Thursday, January 12, 2017 2:34 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] how softICE gui works?
Agree.
I miss SoftICE and Win98 both about as much as I miss my last stomach virus.
SoftICE was always a hack from hell. It was horrifically invasive, full of
hooks and digging into random OS data structures at random offsets. I get
that people liked it because it was fast and allowed single system
debugging. I never warmed to it, personally. Compared to WinDbg, even back
then, SoftICE always felt old and out-of-date to me.
As I remember them, the good old days mostly weren’t so good.
Peter
OSR
@OSRDrivers
—
NTDEV is sponsored by OSR
Visit the list online at:
http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:></http:>
> … you were going to find things worked differently without SoftIce.
Ironically, this is EXACTLY the reasoning behind Linus famous “real programmers don’t need debuggers” stance. Sorry, but no matter how you look it, you just cannot observe a system without actually changing its state ( unless we are speaking about running it under the emulator,of course)
… the hacks in SoftIce as part of its hooks really changed what was concurrent.
Having said the above, I have to admit that SoftIce was, indeed, highly unreliable when it came to debugging memory-mapped IO. I spent almost a MONTH once debugging a non-existent problem that SoftIce made me believe was persistent.
What it was really great for was disassembly - I have learned so much about the Windows internals this way…
Anton Bassov
SoftICE was a brilliant piece of engineering, and the sole, shining beacon of hope for those sad souls cast adrift into the gaping, black, bottomless abyss that was 90’s Win3.x/9x driver development. As a 90’s windows display driver developer (GDI, DirectDraw, Direct3D) (just one of the many hats I wore at the 3D startups) for several different companies in the burgeoning PC 3D graphics revolution, I used SoftICE practically all day every day. SoftICE was my welcome companion when mucking my way through the alternately infuriating and excruciating swamp of incomplete, out-of-date, incorrect, or just plain outright missing MS DDK documentation (often all of these applied simultaneously!).
On most days I didn’t have the luxury of just camping out in the Redmond, WA office of the singular human in the universe who actually KNEW the Win9x display driver “architecture” (there were several such trips!). SoftICE guided me through the maze of twisty little passages of, for example, debugging Alt-TABbing back and forth between full-screen DOSbox VGA and VESA games (Duke Nukem 3D! was really ‘fun’) and the GDI desktop. The SoftICE interface running on the monochrome monitor was the only way debugging this was even feasible.
And now, almost 30 years later, when hit with the itch to revisit “retro” s/w and h/w systems, when I’m going back to investigate running DOS apps on modern hardware (its own ‘adventure’ wrought with peril at every step), SoftICE has stepped up yet again, this time the DOS version, which I had never used before. While investigating the debug tools available for this ancient world, SoftICE again stands alone, dwarfing the functionality and usability and interface of debuggers like TurboC/Pascal and Watcom (from what I’ve seen so far). Yeah, sure, you can run in a VM like QEMU/KVM or an emulator like 86Box or DosBox-x, but the experience is just not the same, it’s not “real” when you’re not running on the actual silicon. And even in those environments, (also including Bochs), the debug experience in 2024 is clunky, full of rough edges, and doesn’t give the smooth experience of SoftICE.
I do not doubt the reports here from others recounting tales of woe with SoftICE’s approach to intrusively hooking kernel structures, but in my 6 years tenure with it I never ran into any issues of that sort. SoftICE was a breath of fresh air in a treacherous trek through Mordor’s poisonous fumes, and with it we successfully shipped product after product. Thank God for SoftICE!
1 Like
SoftICE was a brilliant piece of engineering, and the sole, shining beacon of hope for those sad souls
cast adrift into the gaping, black, bottomless abyss that was 90’s Win3.x/9x driver development
Totally agree. SoftICE was beyond state of the art and its elegant single machine mode could seamlessly debug 16-bit real mode DOS apps, 16-bit protected mode windows apps, and 32-bit flat protected mode windows drivers all at the same time. It was unreal to be able to seamlessly single step through a windows app calling a VxD. This was impossible with things like code view that were child’s toys in comparison. I never bothered with monochrome cards, instead running compatible graphics cards on huge displays with many line mode. I had SoftICE permanently installed on my primary machine into the 2000’s. The efficiency SoftICE added in shipping code out the door was far greater than just about anyone could ever appreciate.
There is nothing like it now. The VS debugger is broken for driver work for years, no one seems to care, and windbg and its archaic interface is junk. Today it is like a roman who remembers the glory days, but now lives in a dark age.
This is another strong personal opinion not universally shared
Which opinion? There is no arguing that SoftICE was a superior product to both wdeb386 and windbg. It was far easier to configure, the user interface was beautiful and (importantly) discoverable – the autocompletion of commands meant you could explore the menus and the command options without having to have a manual, and the product worked the same on the 16-bit systems and the 32-bit systems.