Why do you still use Windows XP?

In article , says...


One idea I really like is Windows Embedded. There are other software
that does something similar. But what basically happens is that all
writes are redirected to somewhere else (like to RAM or to another
drive). So nothing on your boot/system drive is changed at all. Windows
thinks it is writing there and things are written and re-read with the
updated information, although...

When you power off (you don't even have to do a proper shutdown either).

I'd be very careful doing that - there are many documented instances of
the file system getting corrupted that way under XP Embedded with EWF
running. Rare, I grant you, but not worth the risk in my opinion.

--
Zaphod

Voted "Worst Dressed Sentient Being in the Known Universe" for seven
years in a row.

In ,
Zaphod Beeblebrox wrote:
In article , says...


One idea I really like is Windows Embedded. There are other software
that does something similar. But what basically happens is that all
writes are redirected to somewhere else (like to RAM or to another
drive). So nothing on your boot/system drive is changed at all.
Windows thinks it is writing there and things are written and
re-read with the updated information, although...

When you power off (you don't even have to do a proper shutdown
either).

I'd be very careful doing that - there are many documented instances
of the file system getting corrupted that way under XP Embedded with
EWF running. Rare, I grant you, but not worth the risk in my opinion.

How? The system drive is in read only mode and all changes are in RAM
(which you don't want anyway). I can see if you are using another
partition to hold all of the writes that would be a problem. But not if
it is stored in RAM.

--
Bill
Gateway M465e ('06 era) - OE-QuoteFix v1.19.2
Centrino Core Duo T2400 1.83GHz - 2GB - Windows XP SP3

In article , says...

In ,
Zaphod Beeblebrox wrote:
In article , says...


One idea I really like is Windows Embedded. There are other software
that does something similar. But what basically happens is that all
writes are redirected to somewhere else (like to RAM or to another
drive). So nothing on your boot/system drive is changed at all.
Windows thinks it is writing there and things are written and
re-read with the updated information, although...

When you power off (you don't even have to do a proper shutdown
either).

I'd be very careful doing that - there are many documented instances
of the file system getting corrupted that way under XP Embedded with
EWF running. Rare, I grant you, but not worth the risk in my opinion.

How? The system drive is in read only mode and all changes are in RAM
(which you don't want anyway). I can see if you are using another
partition to hold all of the writes that would be a problem. But not if
it is stored in RAM.


I don't know the technical details, but EWF doesn't place the drive in
read-only mode, EWF is just a system-level driver that redirects writes
to RAM instead of disk, and it has been known to fail on power loss in
such a way that the drive gets corrupted. Look in the history of
microsoft.public.windowsxp.embedded for a number of related posts, and
I suspect MS web forums have some also.

--
Zaphod

Arthur: All my life I've had this strange feeling that there's
something big and sinister going on in the world.
Slartibartfast: No, that's perfectly normal paranoia. Everyone in the
universe gets that.

In ,
Zaphod Beeblebrox wrote:
In article , says...

In ,
Zaphod Beeblebrox wrote:
In article , says...


One idea I really like is Windows Embedded. There are other
software that does something similar. But what basically happens
is that all writes are redirected to somewhere else (like to RAM
or to another drive). So nothing on your boot/system drive is
changed at all. Windows thinks it is writing there and things are
written and re-read with the updated information, although...

When you power off (you don't even have to do a proper shutdown
either).

I'd be very careful doing that - there are many documented instances
of the file system getting corrupted that way under XP Embedded with
EWF running. Rare, I grant you, but not worth the risk in my
opinion.

How? The system drive is in read only mode and all changes are in RAM
(which you don't want anyway). I can see if you are using another
partition to hold all of the writes that would be a problem. But not
if it is stored in RAM.

I don't know the technical details, but EWF doesn't place the drive in
read-only mode, EWF is just a system-level driver that redirects
writes to RAM instead of disk, and it has been known to fail on power
loss in such a way that the drive gets corrupted. Look in the
history of microsoft.public.windowsxp.embedded for a number of
related posts, and I suspect MS web forums have some also.

Hi Zaphod! Are you sure this is the right newsgroup?

microsoft.public.windowsxp.embedded

As there are only 15 posts in the last 9 months and most of those are
spam. Also with EWF enabled, it should work very much like a Live OS.

--
Bill
Gateway M465e ('06 era) - OE-QuoteFix v1.19.2
Centrino Core Duo T2400 1.83GHz - 2GB - Windows XP SP3

In article , says...

In ,
Zaphod Beeblebrox wrote:
In article , says...

In ,
Zaphod Beeblebrox wrote:
In article , says...


One idea I really like is Windows Embedded. There are other
software that does something similar. But what basically happens
is that all writes are redirected to somewhere else (like to RAM
or to another drive). So nothing on your boot/system drive is
changed at all. Windows thinks it is writing there and things are
written and re-read with the updated information, although...

When you power off (you don't even have to do a proper shutdown
either).

I'd be very careful doing that - there are many documented instances
of the file system getting corrupted that way under XP Embedded with
EWF running. Rare, I grant you, but not worth the risk in my
opinion.

How? The system drive is in read only mode and all changes are in RAM
(which you don't want anyway). I can see if you are using another
partition to hold all of the writes that would be a problem. But not
if it is stored in RAM.

I don't know the technical details, but EWF doesn't place the drive in
read-only mode, EWF is just a system-level driver that redirects
writes to RAM instead of disk, and it has been known to fail on power
loss in such a way that the drive gets corrupted. Look in the
history of microsoft.public.windowsxp.embedded for a number of
related posts, and I suspect MS web forums have some also.

Hi Zaphod! Are you sure this is the right newsgroup?

microsoft.public.windowsxp.embedded

As there are only 15 posts in the last 9 months and most of those are
spam. Also with EWF enabled, it should work very much like a Live OS.

Yes, that's the right group, but when MS dropped them it died pretty
quickly. You'll have to look well back in the past to see the posts
I'm talking about. Or look in the web forums, I suspect you'll find
similar posts there, but I've not used them so I can't say for sure.

But rest assured, as much as you'd like to think it works like a live
CD, the difference is there - live CDs run on actual Read-Only media
where it is not possible to write to the media, but EWF does not - it
is a system-level driver that redirects writes to memory, and it can
and does fail under the correct circumstances.

30 seconds searching in Google Groups turned up this post and others:

http://groups.google.com/group/micro....embedded/brow
se_thread/thread/304b4d42890bd5aa/1c600bfbdd395133?
hl=en&lnk=gst&q=ewf+corrupt#1c600bfbdd395133

--
Zaphod

Arthur: All my life I've had this strange feeling that there's
something big and sinister going on in the world.
Slartibartfast: No, that's perfectly normal paranoia. Everyone in the
universe gets that.

In ,
Zaphod Beeblebrox wrote:
In article , says...

In ,
Zaphod Beeblebrox wrote:
In article , says...

In ,
Zaphod Beeblebrox wrote:
In article , says...


One idea I really like is Windows Embedded. There are other
software that does something similar. But what basically happens
is that all writes are redirected to somewhere else (like to RAM
or to another drive). So nothing on your boot/system drive is
changed at all. Windows thinks it is writing there and things are
written and re-read with the updated information, although...

When you power off (you don't even have to do a proper shutdown
either).

I'd be very careful doing that - there are many documented
instances of the file system getting corrupted that way under XP
Embedded with EWF running. Rare, I grant you, but not worth the
risk in my opinion.

How? The system drive is in read only mode and all changes are in
RAM (which you don't want anyway). I can see if you are using
another partition to hold all of the writes that would be a
problem. But not if it is stored in RAM.

I don't know the technical details, but EWF doesn't place the drive
in read-only mode, EWF is just a system-level driver that redirects
writes to RAM instead of disk, and it has been known to fail on
power loss in such a way that the drive gets corrupted. Look in the
history of microsoft.public.windowsxp.embedded for a number of
related posts, and I suspect MS web forums have some also.

Hi Zaphod! Are you sure this is the right newsgroup?

microsoft.public.windowsxp.embedded

As there are only 15 posts in the last 9 months and most of those are
spam. Also with EWF enabled, it should work very much like a Live OS.

Yes, that's the right group, but when MS dropped them it died pretty
quickly. You'll have to look well back in the past to see the posts
I'm talking about. Or look in the web forums, I suspect you'll find
similar posts there, but I've not used them so I can't say for sure.

Okay, I thought there were recent discussions about it.

But rest assured, as much as you'd like to think it works like a live
CD, the difference is there - live CDs run on actual Read-Only media
where it is not possible to write to the media, but EWF does not - it
is a system-level driver that redirects writes to memory, and it can
and does fail under the correct circumstances.

Well I never tried it, but I see nothing stopping Embedded from running
from a DVD read only, a ROM, or almost anything else as read only.

30 seconds searching in Google Groups turned up this post and others:

http://groups.google.com/group/micro....embedded/brow
se_thread/thread/304b4d42890bd5aa/1c600bfbdd395133?
hl=en&lnk=gst&q=ewf+corrupt#1c600bfbdd395133

See this is what I am talking about. They have other partitions/drives
that are not under the write protection with the EWF enabled (generally
it is only the system partition). And in these cases, all bets are off
as those other drives are still being written too.

--
Bill
Gateway M465e ('06 era) - OE-QuoteFix v1.19.2
Centrino Core Duo T2400 1.83GHz - 2GB - Windows XP SP3

"BillW50" wrote in :

http://groups.google.com/group/micro....embedded/brow
se_thread/thread/304b4d42890bd5aa/1c600bfbdd395133?
hl=en&lnk=gst&q=ewf+corrupt#1c600bfbdd395133

See this is what I am talking about. They have other partitions/drives
that are not under the write protection with the EWF enabled (generally
it is only the system partition). And in these cases, all bets are off
as those other drives are still being written too.



No-one commented on my post about RAM disk for swap and temp and logging.
Maybe it WAS too insane for all of you?

I suggest you try it. One guy seems to have caught a Windows embedded system
writing files when it was told not to. There are also complexities of the
writefile() API function that can do things in NT kernel OS's, and especially
later ones perhaps, that might damage data if used carelessly (overlapped
mode..). Maybe some M$ coder misused it somewhere. Not least, if you try what
I said you can reduce wear on CF cards that might not all have good 'wear
levelling'. (And SD cards apparently have none!) Corrupting RAM costs less,
you can recover faster, and if you redirect all known writes to RAM disk you
have two easy things to monitor: Anything that writes there, and anything
that still writes somewhere else.

Failing on power loss can affect a CF card. Suppose a write is driver-
redirected to RAM disk. Suppose the power fails, and in that last dying
instant the driver fails, the calling function is still trying to write, or
for whatever other reason the write tries to complete, unredirected. In the
last instant of that instant, a CF card might be written to at the last gasp
of power. This is often fatal for that card, never mind how many partitions
are on it. If this is what is happening, you might be SOL, not a lot you can
do to prevent the risk, except EXPLICITLY make every write operation go to
RAM disk, or wherever you want it to go. Relying on some driver to redirect
stuff is essentially a dangerous conflict of interest, a bit like trusting
other people's web spiders to respect your robots.txt file if you run a
website. If NOTHING at any level is trying to write to a CF card or other
Flash space, it should be safer. I wouldn't use a system that depended on
over-riding dangerous existing behaviour, I'd want to change that behaviour
at source.

It may be that a reduced W98 is inherently safer, because writefile() in that
OS cannot use overlapped mode, and because there are likely fewer things to
be specifically set to write to RAM disk or whatever. That can solve two
major risks for data and media corruption. I wanted to explore this more, and
built a silent solar-powered 1U racked ITX machine with CF cards in ATA
adapters specifically to explore W98 in an 'embedded' method, but I haven't
used it much yet, still got a heat dissipation problem to solve before I
trust it with long run times.

In ,
Lostgallifreyan wrote:
"BillW50" wrote in :

http://groups.google.com/group/micro....embedded/brow
se_thread/thread/304b4d42890bd5aa/1c600bfbdd395133?
hl=en&lnk=gst&q=ewf+corrupt#1c600bfbdd395133

See this is what I am talking about. They have other
partitions/drives that are not under the write protection with the
EWF enabled (generally it is only the system partition). And in
these cases, all bets are off as those other drives are still being
written too.

No-one commented on my post about RAM disk for swap and temp and
logging. Maybe it WAS too insane for all of you?

I suggest you try it.

Try it? I have time and time again. And the only catch I recall about
moving temp files to the RAMDisk is that some updates and software
installs throws files in there that requires a reboot. And most RAMDisk
are wiped clean on reboot. So that was the only problem I have found.
Browser cache and swap files are fine in a RAMDisk.

One guy seems to have caught a Windows embedded
system writing files when it was told not to. There are also
complexities of the writefile() API function that can do things in NT
kernel OS's, and especially later ones perhaps, that might damage
data if used carelessly (overlapped mode..). Maybe some M$ coder
misused it somewhere. Not least, if you try what I said you can
reduce wear on CF cards that might not all have good 'wear
levelling'. (And SD cards apparently have none!) Corrupting RAM costs
less, you can recover faster, and if you redirect all known writes to
RAM disk you have two easy things to monitor: Anything that writes
there, and anything that still writes somewhere else.

First time I've heard that SD cards have no wear leveling. Are you sure
about that? As some of them come with lifetime warrantees. Although I
have suspected that the cheap ones have no wear leveling for a long
time.

Failing on power loss can affect a CF card. Suppose a write is driver-
redirected to RAM disk. Suppose the power fails, and in that last
dying instant the driver fails, the calling function is still trying
to write, or for whatever other reason the write tries to complete,
unredirected. In the last instant of that instant, a CF card might be
written to at the last gasp of power. This is often fatal for that
card, never mind how many partitions are on it. If this is what is
happening, you might be SOL, not a lot you can do to prevent the
risk, except EXPLICITLY make every write operation go to RAM disk, or
wherever you want it to go. Relying on some driver to redirect stuff
is essentially a dangerous conflict of interest, a bit like trusting
other people's web spiders to respect your robots.txt file if you run
a website. If NOTHING at any level is trying to write to a CF card or
other Flash space, it should be safer. I wouldn't use a system that
depended on over-riding dangerous existing behaviour, I'd want to
change that behaviour at source.

Okay now that makes sense and I can see that happening. And one could
avoid this problem electronically by disabling the write enable line.

It may be that a reduced W98 is inherently safer, because writefile()
in that OS cannot use overlapped mode, and because there are likely
fewer things to be specifically set to write to RAM disk or whatever.
That can solve two major risks for data and media corruption. I
wanted to explore this more, and built a silent solar-powered 1U
racked ITX machine with CF cards in ATA adapters specifically to
explore W98 in an 'embedded' method, but I haven't used it much yet,
still got a heat dissipation problem to solve before I trust it with
long run times.

What is generating heat? The CF cards?

And if I were going to run off of solar power, I'd use one of those Asus
EeePCs. They only use like 15 watts tops (the 700 series anyway). And
some have disconnected the fan permanently and have reported no
overheating problems. I don't think the fan on low speed uses much
power, but they have done this mainly to have a totally silent machine.

--
Bill
Gateway M465e ('06 era) - OE-QuoteFix v1.19.2
Centrino Core Duo T2400 1.83GHz - 2GB - Windows XP SP3

"BillW50" wrote in :

In ,
Lostgallifreyan wrote:
"BillW50" wrote in :

http://groups.google.com/group/micro....embedded/brow
se_thread/thread/304b4d42890bd5aa/1c600bfbdd395133?
hl=en&lnk=gst&q=ewf+corrupt#1c600bfbdd395133

See this is what I am talking about. They have other
partitions/drives that are not under the write protection with the
EWF enabled (generally it is only the system partition). And in
these cases, all bets are off as those other drives are still being
written too.

No-one commented on my post about RAM disk for swap and temp and
logging. Maybe it WAS too insane for all of you?

I suggest you try it.

Try it? I have time and time again. And the only catch I recall about
moving temp files to the RAMDisk is that some updates and software
installs throws files in there that requires a reboot. And most RAMDisk
are wiped clean on reboot. So that was the only problem I have found.
Browser cache and swap files are fine in a RAMDisk.


I don't know how WXP handles that but in W9X there's Wininit.ini, which can
be manually raided to see what it's up to. Usually rename of some added file,
to replace an in-use file. I think some of the better installers (Wise, NSIS)
keep a readable record of this too.

(About the swap-on-RAM-disk thing, I expected derision, so good to hear you
tried it. I've seen derision before, but usually from people who didn't know
that if there is enough RAM it pays to let the OS beleive what it is
optimised to beleive, than try to switch off swapping, or any other non-
recommended action).

First time I've heard that SD cards have no wear leveling. Are you sure
about that? As some of them come with lifetime warrantees. Although I
have suspected that the cheap ones have no wear leveling for a long
time.


I definitely read about this, and I wish I could remember where, to cite it.
I do have some anecdotals though.. I made a small GPS logger based on
Sparkfun's Logomatic. That uses an SD card. I saw it fail because I was
deleting logs when extracting them to hard disk. I soon learned to keep them
there till the SD card filled up. This forces wear leveling by the simple
method of causing each bit to be written once each time the card is emptied
and refilled. The failed SD cards were both good quality Kingston cards that
had worked well for years in a case where files had sat on them a long time,
accumulating until I caned off the lot wanting more space. They failed fairly
fast once I started habitually clearing them early, inplying that frequent
writes to one region was the cause of failure. I never lost a CF card when
using it that way, which seems to confirm what I read about those. (I lost
one during a power failure on an adapter during a careless test though).

Failing on power loss can affect a CF card. Suppose a write is driver-
redirected to RAM disk. Suppose the power fails, and in that last
dying instant the driver fails, the calling function is still trying
to write, or for whatever other reason the write tries to complete,
unredirected. In the last instant of that instant, a CF card might be
written to at the last gasp of power. This is often fatal for that
card, never mind how many partitions are on it. If this is what is
happening, you might be SOL, not a lot you can do to prevent the
risk, except EXPLICITLY make every write operation go to RAM disk, or
wherever you want it to go. Relying on some driver to redirect stuff
is essentially a dangerous conflict of interest, a bit like trusting
other people's web spiders to respect your robots.txt file if you run
a website. If NOTHING at any level is trying to write to a CF card or
other Flash space, it should be safer. I wouldn't use a system that
depended on over-riding dangerous existing behaviour, I'd want to
change that behaviour at source.

Okay now that makes sense and I can see that happening. And one could
avoid this problem electronically by disabling the write enable line.


That should do it. Hadn't thought of that.. I'll look into that for my 1U
ITX once I do more work with it.

It may be that a reduced W98 is inherently safer, because writefile()
in that OS cannot use overlapped mode, and because there are likely
fewer things to be specifically set to write to RAM disk or whatever.
That can solve two major risks for data and media corruption. I
wanted to explore this more, and built a silent solar-powered 1U
racked ITX machine with CF cards in ATA adapters specifically to
explore W98 in an 'embedded' method, but I haven't used it much yet,
still got a heat dissipation problem to solve before I trust it with
long run times.

What is generating heat? The CF cards?


CPU. I think my thermal coupling is ok, but even so there's apparently over
ten degrees C difference between case back and CPU thermistor. Which might by
lying for all I know, but it does feel hot after a while. Even a small amount
of forced air makes a huge difference, but that's exactly what I want to
avoid. But I might put a 40mm fan deliberately aimed along the vanes I put
on the back, first forming a cover to compel ducting along the vanes. I think
it might work, and be damn near silent. I considered a heat pipe but that
won't do much better than what I already have even if it wasn't more awkward
and expensive. I can get the heat out to the case, it just won't radiate fast
enough.

And if I were going to run off of solar power, I'd use one of those Asus
EeePCs. They only use like 15 watts tops (the 700 series anyway). And
some have disconnected the fan permanently and have reported no
overheating problems. I don't think the fan on low speed uses much
power, but they have done this mainly to have a totally silent machine.


I considered it. I like what I saw of one of those. They seemed expensive
and fragile though. But I might do it anyway just for the portability.
Especially if they aren't as useless as a hamstrung racehorse of running W98
SE. (I have no idea how well their hardware is supported by W9X drivers...)

I will definitely look up the Asus machines again though, on the strength of
your suggestion. Ever since I quit writing software on a Psion Workabout, I
miss that kind of portability. But those things are about as luxurious as a
Pythoneque Yorkshireman's shoebox, so Asus machines might be worth it if I
can afford a couple (I never want just one, once backup looks like being
vital).

In ,
Lostgallifreyan wrote:
"BillW50" wrote in :

In ,
Lostgallifreyan wrote:
"BillW50" wrote in
:

http://groups.google.com/group/micro....embedded/brow
se_thread/thread/304b4d42890bd5aa/1c600bfbdd395133?
hl=en&lnk=gst&q=ewf+corrupt#1c600bfbdd395133

See this is what I am talking about. They have other
partitions/drives that are not under the write protection with the
EWF enabled (generally it is only the system partition). And in
these cases, all bets are off as those other drives are still being
written too.

No-one commented on my post about RAM disk for swap and temp and
logging. Maybe it WAS too insane for all of you?

I suggest you try it.

Try it? I have time and time again. And the only catch I recall about
moving temp files to the RAMDisk is that some updates and software
installs throws files in there that requires a reboot. And most
RAMDisk are wiped clean on reboot. So that was the only problem I
have found. Browser cache and swap files are fine in a RAMDisk.


I don't know how WXP handles that but in W9X there's Wininit.ini,
which can be manually raided to see what it's up to. Usually rename
of some added file, to replace an in-use file. I think some of the
better installers (Wise, NSIS) keep a readable record of this too.

I just checked this XP Pro machine and it does have a Wininit.ini file.
And I peeked in it and all it has is this one line:

[rename]

(About the swap-on-RAM-disk thing, I expected derision, so good to
hear you tried it. I've seen derision before, but usually from people
who didn't know that if there is enough RAM it pays to let the OS
beleive what it is optimised to beleive, than try to switch off
swapping, or any other non- recommended action).

I've placed the swap in RAMDisk and also used no swap under 2000/XP. And
frankly, I don't see any difference in performance or anything. And when
XP at least gets down to about 200MB of free RAM, trouble starts. Having
more RAM free doesn't have any problems.

The only thing about W2K is that it complains about having no swap file
(or even not large enough), while XP doesn't care. And if W2K has 512MB
or larger swap file (on a machine with 2GB of RAM anyway), W2K stops
bugging you about the swapfile. I have no idea what happens on a W9x
machine. As I never tried it there.

First time I've heard that SD cards have no wear leveling. Are you
sure about that? As some of them come with lifetime warrantees.
Although I have suspected that the cheap ones have no wear leveling
for a long time.

I definitely read about this, and I wish I could remember where, to
cite it. I do have some anecdotals though.. I made a small GPS
logger based on Sparkfun's Logomatic. That uses an SD card. I saw it
fail because I was deleting logs when extracting them to hard disk. I
soon learned to keep them there till the SD card filled up. This
forces wear leveling by the simple method of causing each bit to be
written once each time the card is emptied and refilled. The failed
SD cards were both good quality Kingston cards that had worked well
for years in a case where files had sat on them a long time,
accumulating until I caned off the lot wanting more space. They
failed fairly fast once I started habitually clearing them early,
inplying that frequent writes to one region was the cause of failure.
I never lost a CF card when using it that way, which seems to confirm
what I read about those. (I lost one during a power failure on an
adapter during a careless test though).

I have heard lots of stories about SD and flash drives failing. I never
had one fail yet and some are really old (12+ years I would think). One
guy I know has failures as short as two weeks. Although he constantly
writes to them and uses the dirt cheap ones. All of mine I don't think I
have more than a thousand writes on any of them.

Failing on power loss can affect a CF card. Suppose a write is
driver- redirected to RAM disk. Suppose the power fails, and in
that last dying instant the driver fails, the calling function is
still trying to write, or for whatever other reason the write tries
to complete, unredirected. In the last instant of that instant, a
CF card might be written to at the last gasp of power. This is
often fatal for that card, never mind how many partitions are on
it. If this is what is happening, you might be SOL, not a lot you
can do to prevent the risk, except EXPLICITLY make every write
operation go to RAM disk, or wherever you want it to go. Relying on
some driver to redirect stuff is essentially a dangerous conflict
of interest, a bit like trusting other people's web spiders to
respect your robots.txt file if you run a website. If NOTHING at
any level is trying to write to a CF card or other Flash space, it
should be safer. I wouldn't use a system that depended on
over-riding dangerous existing behaviour, I'd want to change that
behaviour at source.

Okay now that makes sense and I can see that happening. And one could
avoid this problem electronically by disabling the write enable line.

That should do it. Hadn't thought of that.. I'll look into that
for my 1U ITX once I do more work with it.

SD cards also have a write protect switch and some USB flash drives does
too. Although I noticed that SD cards when used with some (maybe all)
USB card readers ignores the switch setting. And I never investigated
why this happens. I would suspect though, that line isn't wired on those
card readers.

It may be that a reduced W98 is inherently safer, because
writefile() in that OS cannot use overlapped mode, and because
there are likely fewer things to be specifically set to write to
RAM disk or whatever. That can solve two major risks for data and
media corruption. I wanted to explore this more, and built a silent
solar-powered 1U racked ITX machine with CF cards in ATA adapters
specifically to explore W98 in an 'embedded' method, but I haven't
used it much yet, still got a heat dissipation problem to solve
before I trust it with long run times.

What is generating heat? The CF cards?

CPU. I think my thermal coupling is ok, but even so there's
apparently over ten degrees C difference between case back and CPU
thermistor. Which might by lying for all I know, but it does feel hot
after a while. Even a small amount of forced air makes a huge
difference, but that's exactly what I want to avoid. But I might
put a 40mm fan deliberately aimed along the vanes I put on the back,
first forming a cover to compel ducting along the vanes. I think it
might work, and be damn near silent. I considered a heat pipe but
that won't do much better than what I already have even if it wasn't
more awkward and expensive. I can get the heat out to the case, it
just won't radiate fast enough.

Oh ok. Those EeePCs uses the keyboard as one giant heatsink for the CPU
and Northbridge. They mainly did this is save weight by eliminating a
heatsink. The Celeron 900MHz is also clocked down to 633MHz. And I have
never seen the CPU go over 140 degrees F ever. And the fan is on the
other side of the motherboard and doesn't help much on the CPU and
Northbridge side. The fan side has the RAM, SSD, and WiFi card and that
is all. And the fan speed is controlled by the CPU temperature, go
figure.

So underclocking will help lots in regards to temperature. So that is an
idea. And frankly I can toggle the speed between 900MHz and 633MHz and
there isn't much of a performance difference. Even if you have the CPU
maxed out for hours.

As for measuring temperatures, I use one of those IR temp probes. You
are supposed to calibrate it on the each surface you are measuring (they
can measure air too). I never did that since testing against other
thermometers, I don't think it is off more than a degree or two without
the calibration. They cost like $25 and under.

And if I were going to run off of solar power, I'd use one of those
Asus EeePCs. They only use like 15 watts tops (the 700 series
anyway). And some have disconnected the fan permanently and have
reported no overheating problems. I don't think the fan on low speed
uses much power, but they have done this mainly to have a totally
silent machine.

I considered it. I like what I saw of one of those. They seemed
expensive and fragile though. But I might do it anyway just for the
portability. Especially if they aren't as useless as a hamstrung
racehorse of running W98 SE. (I have no idea how well their hardware
is supported by W9X drivers...)

I will definitely look up the Asus machines again though, on the
strength of your suggestion. Ever since I quit writing software on a
Psion Workabout, I miss that kind of portability. But those things
are about as luxurious as a Pythoneque Yorkshireman's shoebox, so
Asus machines might be worth it if I can afford a couple (I never
want just one, once backup looks like being vital).

I don't think they are really that fragile. I have seen youtube videos
of people abusing them and they are really tough even while running. The
only worry I have is the screen. The 7 inch ones are really protected
from the sides. Although the screens will still break if someone sits on
one. The only other weak spot would be the common problem of the DC
jack. One good sideways pull just might screw that up, but otherwise
should be fine.

W98 drivers? It uses Intel 915GM chipset and I believe Intel has W98
drivers for them. Same for the video. The audio I think is realtek or
something and I am not sure about drivers for them. The WiFi and the
webcam might be the hardest to get running under W98. I should try this
someday. ;-)

I should add that I have high CPU usage from DPC (interrupts) while
running XP. I believe I tracked it down to the WiFi driver. While I am
still doing more tests on this to make sure. And I haven't seen this
problem with Windows 2000 yet. But I am using a different WiFi driver
there, so maybe that is why (and that driver should work fine under XP
too). It also appears that when you do a fresh XP install, no problem.
It only seems to appear after a restore from a backup. And this doesn't
make any sense to me and why I need to test this out more.

Another deal breaker might be something that I think affects all Celeron
M machines. That is when powered down, they still draw power from the
battery. Enough to drain a full battery after a week or two. The
temporary fix is to remove the battery and reinsert after a few seconds.
As I believe this stops the drain.

--
Bill
Gateway M465e ('06 era) - OE-QuoteFix v1.19.2
Centrino Core Duo T2400 1.83GHz - 2GB - Windows XP SP3