I have a program written in CA-Clipper 5.2 and linked with Blinker 7. I recently learned how to compile it into protected mode in place of real mode. Now the real mode debugger won't work with the program. So now I need a way to debug my code. The documentation for Blinker says to use "NuMega SoftICE" or "Periscope". I'm not family with those debuggers, and can't find much on them from Google. It sounds like SofeICE was turn into some type of hacking tool. Any suggestion on a way to debug my program?
NuMega was bought out, and SoftICE was killed (something like five years ago, if memory serves). It was a kernel debugger, which is a kind of tool some hackers (in either sense of the word) find useful, but wasn't really a hacking tool as such. (Silly trivia of the day: people who beta-tested the original version of SoftICE for Windows NT got a T-shirt that read: "...and they said it couldn't be done!").
Periscope is (was) an in-circuit emulator. It was a board with a plug to fit into your CPU socket, and a socket where you put the original CPU. It would then monitor all the traffic over the CPU bus, providing a lot of debugging capability that most software debuggers can't even hope to match. As CPU buses got faster, however, it got extremely expensive, and eventually got to the point that there was no market left. There was definitely a version for the 486 (I've used it), but I don't think there was ever a version for the Pentium or newer.
As to what you would use: the HX DOS Extender is probably the only DOS Extender still maintained. Their page lists debuggers that can be used with it. I certainly can't guarantee compatibility with the DOS extender you're using, but there's at least a chance one of them might work.
try watcom debugger with commandline startup: wd /tr=rsi
trap for rational systems dos extender
be sure to get latest version: open-watcom-c-dos-1.9.7z
it has problems doing search
but earlier versions do not work well
Related
Installation of a device Driver on Windows 8 Fails with the following error:
0xe000022d -536870355 ERROR_NON_WINDOWS_NT_DRIVER
The decimal number was what I found in the error log (C:\Intel\Logs\IntelGFX.log), and a web search turned up the error Symbol Name.
As I downloaded the Driver straight from Intel (Intel® Graphics Media Accelerator Driver for Windows* XP), I do believe that it is an NT Driver. Just not for Win7 or Win8, but for XP and possibly adapted for Vista.
The device in question doesn't do Aero, but I don't Need Aero, so turned it off. I would, however, love to have the native Resolution and Hardware acceleration. Which is why I would love this Installation to succeed.
My assumption is that the Driver Installation Routine (the Intel Driver Setup program) interacts with the operating System in some ways in order to determine how exactly to install the Driver, and by way of prudence it barfs at the first sights of Errors; so that in theory a user who deems he knows better should be able to force the Installation. (It's only a preview System with no real data or functionality at the Moment, so why not Play around a Little.)
(1) Any idea what this error really means?
(2) Any way to Bypass the regular Driver Installation? Sort of force-install the Driver?
(3) Pointers like "What every programmer Needs to know about device Drivers" are also welcome, as a fallback to #1 and #2.
I found this error code documented in the SetupAPI on the DIF_ALLOW_INSTALL request page, but I know next to nothing about this API.
Okay, Ken's arguing this is not a programming question, and he might have a point. Trouble is: hard for me to make the programming point due to my lack of knowledge in the Driver department. This much I know: The Win32 API allows you to Register code to run when API routines get called. This is called "hook" in programmer lingo, and it's a concept I'm familiar with. The idea would be that you could somehow insert some code between the OS and the Driver Setup Routine to return "all great, go on" instead of ERROR_NON_WINDOWS_NT_DRIVER. But I've never done that at the System/Driver Level.
It is true that this is not a concrete programming question. Way to go for me to get there.
I posted this on stackoverflow because I deemed it too hard for superuser and off-Topic for serverfault. If you could suggest a better Forum that would also be helpful.
Hardware background: The Driver in question is for a 2005 vintage Hardware (Samsung X20 notebook) featuring an Intel 915GM/GMS, 910GML chipset. Not enjoying Hardware Support and falling back on some VGA Driver is obviously somewhat detrimental to the overall user experience.
(I excuse for undue capitalization in this post - this is due to the new spell-checker in IE10 which I haven't managed to disable yet.)
How are operating systems typically debugged? They cannot be stepped through with a debugger like simple console programs, and the build times are too large to repeatedly make small changes and recompile the whole thing.
They aren't debugged as a multi-gigabyte programs! :)
If you mean the individual user-mode components, they can mainly be debugged just like normal programs and libraries (because they are normal programs/libraries!).
For kernel-mode components, though, each OS has its own mechanism; here is some information regarding the way that we do kernel debugging in Windows. It can be done using the help of another machine connected to the machine you're debugging, via a serial port or something. I'm not familiar with the process itself, but that's the gist of how they work. (You need to set some boot loader options so that the system is ready for the debugger to be connected as early as possible.)
It depends on which part of the operating system you're talking about. When I worked at MSFT, I worked on the IE team. We debugged IE and the shell (Windows Explorer) in Visual Studio and stepped through them line by line all day long. Though, sometimes, it's easier to debug using a command line tool such as NTSD.
If, however, you want to debug anything in Kernel land such as the OS kernel or device drivers, which I suspect is really what you're asking, then you must use the Kernel debugger. For Windows that is a command line tool called kd, and generally you run the debugger on one machine and remotely debug the target.
There are a whole set of techniques throughout history from flashing lights on the console, to the use of hardware devices like an ICE, to more modern techniques utilizing fairly standard debuggers. One technique that is more common among OS developers then application developers is the analysis of a core dump. Look at something like mdb on solaris for ideas about how Solaris kernel developers do some of their debugging. Also tracing technologies are used. Anywhere from fairly straightforward logging packages to more modern techniques like dtrace.
Also note that the techniques used depend on the layer of software. Initial boot tends to be a fairly hard place to get your fingers into. But after that the environment of modern operation systems looks more and more like the application setting you are use to. In the end, it is all code :)
Someone I used to work for emailed me out of the blue and said they want me to update a VB3 (!!!) program I wrote for them because customers are reporting having problems running it under Windows 7. They have lost the source code (natch). Is there a decompiler for VB3?
For decompiling VB "DoDi VB3 decompiler" is the best tool available. The results are pretty good.
However the original is anno 1997. VB3 is 16 bit code only + still some bugs + no source code. These makes that tool hard to get running on windows beyond Windows XP and limits it's use.
DoDi's VBDIS3 it self is also written in VB3 - so about 10 years later just for fun I cracked it to make the decompiler to decompile it self.
... and ported it to VB6!
So now you've the source code !!! :D
... and it's 32 Bit code + some bugfixes and improvements to the original:
DoDi's Visual Basic 3 Decompiler [Reloaded]:
http://vbdis4.angelfire.com
Screenshoot:
in case that website get lost Google for
'VBDIS3.67e_Reloaded_Rev3_DoDi_s_VB3Decompiler.7z'
or try the internet archive
http://web.archive.org/web/20090301170633/http://vbdis4.angelfire.com
I remember looking for Visual Basic decompilers/disassemblers a long time ago to no avail. There may be things out there now though. The most I could come up with was PE Explorer: http://www.heaventools.com/overview.htm
Have you suggested running your application under Windows Compatibility mode: http://www.sevenforums.com/tutorials/316-compatibility-mode.html
Edit: Further Googling: http://www.w7forums.com/visual-basic-3-0-compatible-64-bit-version-t5146.html
I maintain legacy 16-bit VB3 software
that is compatible with Windows 7 and
have done a lot of research in this
area.
16-bit applications will not natively
run in Windows 7 64-bit full stop.
This is because when a 64-bit capable
CPU is started in 64-bit mode, it
cannot change into 'real mode' (the
mode used by 16-bit applications)
without a hard reset. If a processor
is in 32-bit mode, it can swap between
real mode and protected mode at will.
The only workaround here is a virtual
machine- Windows 7 comes with a free
version of Windows XP which is usable
inside a custom version of Microsoft
Virtual PC. Google for "Windows 7
Virtual XP Mode". Once your copy of
Windows 7 has been validated as
authentic, it will allow you to
download Virtual PC and the XP Image.
It's definitely not a pretty solution,
but the only option for my customers
who have gone ahead and bought a
64-bit OS without checking to see if
their installed software is 64-bit
compatible.
Unlike the later versions which used native code and are generally not reliably decompilable, VB3 (and, I think, VB4) could be usually decompiled to almost original code. The keywords you need to search for are "DoDi VB3 decompiler" or "vb3dis". Here's a page that seems to have a copy.
Really? VB3, if it runs fine in XP, should be okay in the Windows compatibility box.
What I would do is to say that you couldn't find anything suitable (which is almost certainly true) but that you may be able to fix their problem for a moderate fee. Then, hopefully it's just a matter of setting a flag on the application (you may want to check this first to ensure it won't be too much work).
Money for Jam.
The other option is that you can offer to rewrite it for them in a more modern setting, using your vast knowledge of the application.
However, I'm surprised you don't have a copy lying around. I keep just about every piece of software I've ever written just in case (with permission for work-for-hire stuff of course), even down to the Fortran assignments I did at Uni back in the early 80s.
That's a good habit to get into, although I'm starting to wonder whether I should perhaps free up some space by ditching the Fortran :-)
There are a number of things you can do to help them without the source code. You could apply an external manifest if the application will only work when it is elevated. You could advise them to install the application somewhere other than Program Files (generally an awful idea, but might work in this case.) You could apply a compatibility setting or teach them how to install it into "XP mode" so it runs in an XP virtual machine.
Failing all of those, you could offer to rewrite it in VB.NET so they would get a more modern ui, Windows 7 features (not just capabilities) and would actually own the source code for their app. That might have value for them.
And yes, you should have kept the code. I have CDs burned from my old projects going back to the dawn of time (at some point I copied things from 3.5" backups to CDs while I still had some machines that could do both) and I have made more than one previous client happy by sending them the CD. It is a really cheap marketing investment, really.
It sounds like this is an application that is sold to customers, and is having trouble or doesn't work under Windows 7.
Consider advising the customer that the application should be:
modernized, thereby easing the ability to add features/maintained
otherwise run in XP Compatibility mode for their Windows 7 customers. Surely that number will only grow, and would become a support issue. Goto previous bullet.
Seriously though; your customer should realize that their software needs to be modernized. Hopefully you can persuade them of that long term goal; perhaps they already know that.
I was going through some general stuff about operating systems and struck on a question. How will a developer debug when developing an operating system i.e. debug the OS itself? What tools are available to debug for the OS developer?
Debugging a kernel is hard, because you probably can't rely on the crashing machine to communicate what's going on. Furthermore, the codes which are wrong are probably in scary places like interrupt handlers.
There are four primary methods of debugging an operating system of which I'm aware:
Sanity checks, together with output to the screen.
Kernel panics on Linux (known as "Oops"es) are a great example of this. The Linux folks wrote a function that would print out what they could find out (including a stack trace) and then stop everything.
Even warnings are useful. Linux has guards set up for situations where you might accidentally go to sleep in an interrupt handler. The mutex_lock function, for instance, will check (in might_sleep) whether you're in an unsafe context and print a stack trace if you are.
Debuggers
Traditionally, under debugging, everything a computer does is output over a serial line to a stable test machine. With the advent of virtual machines, you can now wire one VM's execution serial line to another program on the same physical machine, which is super convenient. Naturally, however, this requires that your operating system publish what it is doing and wait for a debugger connection. KGDB (Linux) and WinDBG (Windows) are some such in-OS debuggers. VMWare supports this story explicitly.
More recently the VM developers out there have figured out how to debug a kernel without either a serial line or kernel extensions. VMWare has implemented this in their recent stuff.
The problem with debugging in an operating system is (in my mind) related to the Uncertainty principle. Interrupts (where most of your hard errors are sure to be) are asynchronous, frequent and nondeterministic. If your bug relates to the overlapping of two interrupts in a particular way, you will not expose it with a debugger; the bug probably won't even happen. That said, it might, and then a debugger might be useful.
Deterministic Replay
When you get a bug that only seems to appear in production, you wish you could record what happened and replay it, like a security camera. Thanks to a professor I knew at Illinois, you can now do this in a VMWare virtual machine. VMWare and related folks describe it all better than I can, and they provide what looks like good documentation.
Deterministic replay is brand new on the scene, so thus far I'm unaware of any particularly idiomatic uses. They say it should be particularly useful for security bugs, too.
Moving everything to User Space.
In the end, things are still more brittle in the kernel, so there's a tremendous development advantage to following the Nucleus (or Microkernel) design, where you shave the kernel-mode components to their bare minimum. For everything else, you can use the myriad of user-space dev tools out there, and you'll be much happier. FUSE, a user-space filesystem extension, is the canonical example of this.
I like this last idea, because it's like you wrote the program to be writeable. Cyclic, no?
In a bootstrap scenario (OS from scratch), you'd probably have to introduce remote debugging capabilities (memory dumping, logging, etc.) in the OS kernel early on, and use a separate machine. Or you could use a virtual machine/hypervisor.
Windows CE has a component called KITL - Kernel Independent Transport Layer. I guess the title speaks for itslf.
You can use a VM: eg. debug ring0 code with bochs/gdb
or Debugging NetBSD kernel with qemu
or a serial line with something like KDB.
printf logging
attach to process
serious unit tests
etc..
Remote debugging with kernel debuggers, which can also be done via virtualization.
Debugging an operating system is not for the faint of heart. Because the kernel is being debugged, your options would be quite limited. Copious amount of printf statements is one trick, and furthermore, it depends on really what 'operating system' is being debugged, we could be talking about
Filesystem
Drivers
Memory management
Raw Disk input/output
Screen input/output
Kernel
Again, it is a widely varying exercise as in the above, they all interact with one another. Even more complicated is the fact, supposing you were to debug the kernel, how would you do it if the runtime environment is not properly set (by that, I am talking about the kernel's responsibility for loading binary executables).
Some kernels may (not all of them have them) incorporate a simple debug monitor, in fact, if I rightly recall, in the book titled 'Developing your own 32bit Operating System' by Richard A Burgess, Sams publishing, he incorporated a debug monitor which displays various states of the CPU, registers and so on.
Again, take into account of the fact that the binary executables require a certain loading mechanism, for example a gdb equivalent, if the environment for loading binaries are not set up, then your options are quite limited.
By using copious amount of printf statements to display errors, logs etc to a separate terminal or to a file is the best line of debugging, it does sound a nightmare but it would be worth the effort to do so.
Hope this helps,
Best regards,
Tom.
Is there any small tool that gives me access to the data gathered by the Intel CPU Counters (like L1/L2 cache misses, branch prediction failures ... you know there are hunderts of them on modern Core2 CPU's).
It must work on Windows (while being able to use it with Solaris, FreeBSD, Linux, MacOSX would of course be nice).
Check out the Intel PCM (Performance Counter Monitor) tool which does exactly what you want to do.
Link: https://software.intel.com/en-us/articles/intel-performance-counter-monitor-a-better-way-to-measure-cpu-utilization
Intel PCM provides a rich API that allows you to instrument your code. Furthermore, to date, PCM is the only tool to read uncore events too.
This thread seems a little old but if you're still interested, I wrote a howto recently on this topic using nothing more than rdmsr and wrmsr in Linux. It only deals with the performance counters on an Intel uncore for Westmere, but the process I described might help you figure out what you need if you haven't already. I'm sure Windows has some equivalent program or function call to RDMSR and WRMSR. The problem is you need to be ring 0 (kernel mode) to read MSRs. I have no idea how to do that in Windows. I won't be able to help with any Windows questions but may be able to answer some MSR-related questions if you have any. I'm by no means an expert though.
PAPI is a very promising lead, however, I believe they discontinued support for Windows (and therefore .NET C#) quite a few years ago.
On the windows front, Visual Studio 2010 Premium comes with performance explorer. If you run any project or binary in instrumentation mode, you can get access to hardware events such as instructions retired.
The results can be somewhat mixed and inconsistent depending external factors, but it integrates with Visual Studio nicely and you get detailed counts (avg, maximum, total) on a per method/module level.
Intel V-tune performance analyzer also exposes these natively. I haven't played with this tool yet but it might be a more flexible API than what Visual Studio 2010 exposes.
You didn't write of your are looking for a application or for a library.
For Windows there is Intel VTune. But this not exactly an small tool. For linux I have used oprofile, which works without kernel patches.
On OS X, Shark lets you get data from the PMCs. I'm not sure what's available on Windows other than Intel's tools (VTune, as mentioned by drhirsch).
Try this
http://icl.cs.utk.edu/papi/
It is a full library that allows you to read any CPU counters data, works both on Windows and Linux [and other OS]
This thread looks pretty old. But still, all the above mentioned counters are available at Intel PCM .These counters can be used as a Microsoft Perfmon plugin or a command prompt interface. The Intel PCM gives informations like L2 and L3 cache hit ratio, cache misses etc.