Mijzelf

CORE CORK CORF

PYKE. Yet another river

TAGO. Yet another river

No USB.

POUR has already been used. TOUR

LOUP, yet another river

You shouldn't install Windows from the desktop. Just copy the \Win95 or \Win98 directory from the CD to the laptopdisk. (+/- 100MB) Put the disk back in the laptop, boot the laptop from floppy, and run C:\Win95\Setup.exe

No, of course not. 12 years ago usb was not invented yet, so how could the the BIOS detect an USB interface? There are serveral ways to get your installation files on that laptop. 1) Buy a pcmcia network card. In combination with a Network Boot Floppy you should be able to copy them from a network share. 2) Use a serial crosscable and a dos bootfloppy with Telix to transmit the files. (On the other side you could use Hyperterminal). 3) Use a 2.5" to 3.5" convertor to put the laptop drive in a desktop machine to be preloaded.

http://www.macronix.com/QuickPlace/hq/Page...C/?OpenDocument

Two long shots: 1) You write you can't install W2000 with acpi hal. Did you already try to exchange the kernel/hal after you completed installation? 2) It is possible to backup the activation, so you won't have to reactivate when you reinstall. The first time activation is still needed, however.

There is no legal way to activate that XP installation, besides getting that sticker back. And if that XP is an OEM version (in case of laptops almost always), you're not even allowed to install it on another computer anyway. So the only legal way out is to buy a new license, or to use a free OS, like Ubuntu.

While this is possible, it's not a good idea. The first stage in the booting process W9x is dependent to the BIOS. So if only one file which is needed in this stage is placed above the 128GiB limit, the system won't boot anymore. This situation could be achieved by a simple defragmentation.

REIS

@Idontwantspam: NOTS3W already did: @DL: I've been thinking about this. From point of information, the 'simple' approach is: Each man dies or not, containing 1 bit of information. So 8 men can find a poisoned bottle in 2^8=256 bottles. Given you've got enough time, on man could do this. Drink one bottle, wait, if he didn't die, take the next bottle. Etc. The information is now not the dieing itself (he *will* die), but the exact moment he dies. Your approach is a combination of these two, because you don't have enough time. AFAICS you can divide the original 1000 bottles in 9 groups (no man dieing marks the 9th group). Then you've got at least 7 men remaining, so you can divide the selected group in 8. etc. With four iteration steps you should be able to find the bottle in 9*8*7*6=3024 bottles. (Actually a few more, the 9th group can be bigger than the others, because you will have 8 men left to investigate this group, and this recurses also). 2nd answer to DL: Sorry I was not more clear. I forgot to mention that in the second case the time can be reused. Give the man 1 bottle, one minute later the second, etc. After nine days and a 1000 minutes you can know which bottle was poisoned, *if* the poison is accurate enough to let a man die in 9 days +/- 30 seconds. (Actually, you have a whole day to spend, this gives you 86 seconds for each test). Because this constraint is unlikely, you'll have to use use a longer period for each test. So I tried to reacon what is the largest possible number of bottles which could been tested given 8 man in 4 shifts, as you suggested, which is at least 3024. And this case you can also reuse the time, by using a smart scheme, as you did. So yes, you are right. Your scheme will find the bottle. (if the poison is accurate enough for 9 days +/- 3 hours (as you can use a period of 6 hours between the tests)). Small gloss: your scheme is a waste of prisoners. In your 'clarified picture' all prisoners are dead after the 4th test, while 1 dead man per shift is enough.

GAIL. Yet another river And a new list:

A new one. Three men go fishing, and hire a boat. The boatlessor charges them for $30, so each man pays $10. While the men are walking to the landing-stage, the lessor remembers that the price is $25, so he sends his boy with $5 restitution. The boy decides that dividing $5 in three men is difficult, so he puts $2 in his pocket, and gives each man $1. Now each man has paid $9, $27 in total. The boy has $2, that makes $29. Where is the remaining dollar?

I don't have perfectly clear how you want to do this, but it seems to me that you forget that a prisoner cannot survive the 2nd hour, when he already died the 1st.

3. Because 'ten' has three characters. @spacesurfer: I know.

WAAL a river

That's not a Windows 95 limitation, that's a FAT32 limitation and you cannot use NTFS, thus, you're SOL. It is both a W9x and a FAT limitation. FAT uses a 32 bit field to define the size of a file in bytes, which makes a maximum of 4GiB - 1 byte. W9x uses a 32 bit filepointer to address the data to be read or written, which gives a maximum of 4GiB. BTW, all flavours of FAT use a 32 bit filesize. So FAT12 can describe 4 GiB-1 file, while it cannot store it (FAT16 can, link) /edit: I'm talking about the file size limit, not the file set size counter limit. Should learn to read.

Of course you could subdivide the 1024 bottles in 256 parts, but then the King would waste 3 bottles, which is unacceptable.

SIAM

http://www.petri.co.il/forgot_administrator_password.htm

SNOT And a new list:

The most interesting part of a Dr.Watson log is around the 'Fault ->' part. In this case: What you see here is the code around the crash, the value of the processor registers at the moment of the crash, the exact crash point, and a stackdump, which contains information about which functions are calling each other. From bottom up: RtlFreeHeap which is located in ntdll.dll calls CorLaunchApplication which is located in mscorwks.dll, which calls CoTaskMemFree in ole32.dll.... Unfortunately this list of functions can be wrong when something has damaged the stack. A buffer overflow can do that. In this case, the crash is a hardcoded break (int 3). So the program has found that someting is serious wrong, and tries to jump to the debugger. The list RtlFreeHeap->CoTaskMemFree->DbgBreakPoint suggests that is has someting to do with memory management. Maybe a com-object wich is released twice, or an allocated buffer which is filled up beyond it limits.