Two days in a row now I’ve had Eudora stop working. As in, the program shuts down abruptly and then can’t be restarted. After a bunch of experimenting and reinstalling I discovered that the problem seemed to lie in a particular ‘mailbox’ – the first time the ‘trash’ box, the second time the ‘in’ box.
I say that that was the problem because after taking both of that mailbox’s files (.toc and .mbx) out of the folder Eudora worked properly, and returning the files to the folder recreated the problems. My guess is that something happened to one of the files so the index and database were incompatible. Just an ignorant guess.
Also, the second time I noticed that the year of the system date had been changed to something really odd…like 2075, maybe.
Now, I’ve never had either of those problems before – I’ve been using Eudora for well over a decade.
The only thing I’m aware of got changed is that I reinstalled a very ancient platform game, Crystal Cave. I’m sure the game isn’t infected, I installed it from the manufacture’s disk that I’ve had since I played it on my first DOS computer way back when.
Anyway, I had Eudora running, and then spent some time playing CC. It was after I closed Crystal Cave that I found Eudora had crashed. The sequence the next night was basically the same.
So…Is it possible that playing this old DOS game is what is screwing up the other programs?
Note: Between the first and second occurance I updated and ran Spybot and AdAware, and did a full system scan with AVG. And I have AVG running all the time. Nothing turned up except a couple of data mining cookies.
I post mainly to say I reported it for you, but also to say that I’ve used Eudora and played old DOS games and nothing similar has ever happened to me. Little help, I know.
How are you running the DOS game? An emulator like DosBox? Or are you running it natively?
One of the biggest problems with DOS is that different programs could interfere with each other quite easily if a programmer made a mistake. IIRC, this problem plagued Windows 95 and Windows 98 to some extent as well if you tried to run old DOS programs on them. I don’t think that you should run into any such problems on Windows 2000 or later.
My best guess would be that you hit a bug in Eudora, though.
A couple of ways that can sometimes fix such a damaged mailbox:
the Eudora command ‘compact mailboxes’ under the ‘Special’ menu.
delete or move elsewhere just the table-of-contents .toc file, but leave the actual /mbx file. Then when you restart Eudora, it will note that the index for this mailbox is corrupted, and ask if you want it to rebuild the index.
I think the system date error is significant. See if running the game trashes the system date.
Back in the early DOS days it was not uncommon for machines to wake up at 1/1/1980 every time they were turned on. So having an ordinary app look at & reset the date is not unheard of. But with the changes in the internal storage of date info since the old days, it’d be beleiveable that the date is getting rest to what now amounts to a silly value.
In general, a wonky system date will not be a happy experience for many programs which manipulate disk files. Almost any question involving “which item is newer?” will give bogus answers if one or the other was created/saved/updated when the date was wrong. So IF this program is trashing the date, yuo’ll want to run as little ele as possible when it’s in use, and remember to reset the date correctly when you’re done with it.
WindowsXP Home. Um…I started the game by clicking on the .exe file. Natively?
I remember reading once that on startup Eudora reads the In, Out, and Trash mailboxes into memory, and then writes them out when the program closes. Given that the two problems involved two of those mailboxes (rather than any of the 36 others I have), doesn’t it seem likely the problem came from some bit of memory getting changed that shouldn’t have been?
Anyway, I’ve run Eudora multiple times in the about 24 hours since I last ‘fixed’ it, and HAVEN’T run the old game, and no problems. Fingers crossed.
asterion, I don’t have Dosbox, but maybe I should look into it. In the meantime, I’m simply not going to touch that game again.
Good to know, thanks! I’m not worried about the Trash mailbox I lost, and I already spent several hours yesterday digging through the old in box with a wp program, but at least it offers hope if the problem does recur.
LSLGuy – right now I’m afraid of that game, but I will definitely check the date if I get brave enough to try it again.
Unless the Windows XP programmers are totally incompetent(not that I’m necessarily ruling this out), this absolutely cannot happen. Modern operating systems use what’s called “memory protection” to prevent exactly this. Basically, the operating system tells the hardware that Eudora is only allowed to write to certain parts of memory, and your game is only allowed to write to different parts of memory. If a program tries to write to memory that it’s not allowed to access, the hardware tells the operating system that some program is breaking the rules, and the OS will usually kill the offending program.
When Dos was originally written, the hardware it was running on didn’t have the ability to deny programs access to memory they didn’t own, so these kind of things could happen.
Really old DOS games could possibly mess with all sorts of things. I suspect some of them could mess up your case and power supply.
One DOS game we had involved a plot and timeline set in the future. The game would reset the system clock to facilitate this. If you look at the game funny, it would crash, so whatever exit procedure it might have run to reset the date would get passed by.
In fact, some old DOS games had to crash. That is, some of them could not terminate and return control to command.com. You had to hit the reset button or turn off the switch.
>Modern operating systems use what’s called “memory protection” to prevent exactly this.
Tell me more about this. While not certain, I think there’s a “memory protection” that isolates the stack and heap areas, though not the code areas, for separate threads (which is what throws a “memory protection fault” exception during some bugs). I sorta think this is what was meant by “protected mode” introduced in the Intel 80286, which the DOS of that day did not support but which some specialty software did (maybe PharLap had one of these). But what you mention sounds more like the OS making sure to flush the buffers when applications terminate, or like the “sync” command in UNIX. So what exactly do you mean?
I’m talking about the OS using paging and virtual memory to protect different processes’ memory from one another. I can go into more detail if you like.
Incidentally, 286 memory protection was implemented with segmentation, which pretty much everybody agrees was a bad idea. It was the 386 that brought paging to the x86 line.
Also, individual threads are not protected from one another. That’s one of the basic differences between threads and processes.
Modern OS’s, including current Windows versions, use separate memory spaces for each application. No application can directly read or write to the address space of another application. With Windows, parts of the OS itself run in a privileged state, which you can see with the CPU Usage History graph of the Performance tab of Task Manager (you will have to check the View -> Show Kernel Times option); the green line shows total CPU time, and the red line shows kernel CPU.
When a process starts up, the OS creates an address space, and then allocates blocks of memory for things like the stack, heap and program code image. A memory protection fault is when an application tries to access part of its own address space that hasn’t been allocated. By far the most common bug that causes this is using a pointer that hasn’t been initialized properly. In C or C++, the following code illustrates this:
I saw code akin to this a few years ago; the original programmer didn’t realize that the MSG_PEEK option still read data into the buffer, generating an access violation exception every time the code was executed with the PeekOnly flag set to true. As an aside, if a program crashes out with such an exception, it’s often the sign of sloppy programming; bugs are inevitable, not handling exceptions programmatically is usually just laziness.
PharLap was a library that allowed you to build applications that could access the 32-bit address space, rather than being confined to DOS’s 20-bit, segmented space.