Once upon a time there was Windows CE 1.0. When I first started using these O/Ses, it was a little bewildering how Micrsoft named all of these operating systems, and I started with Windows CE 2.0 for Handheld PCs (with small keyboards). Palm-sized PC’s, now called Pocket PC’s have no keyboard.
Back then in 1999, you needed Visual Studio 6.0 to compile to Windows CE 2.0 and the Windows CE Toolkit for Visual Studio 6.0 to make it happen. You *still* have to use the same platform today as nothing of theirs is backwards compatible, and worse yet, the 2002 refresh of Embedded Visual C++ 3.0 for Pocket PC 2000 (Windows CE 4.2) puts your registry in a state such that you cannot go back without manually deleting registry keys related to the Platform manager, and there are no error messages of course, just crashing. I believe there was a later version of the CE Toolkit (no longer available?) that handled Windows CE 2.1 and 2.11.
eVc 4.0 can compile for Windows CE 4.2 and 5.0, I believe. The latest Visual Studio 2005 now in beta, superceding Visual Studio .NET can handle Windows CE .NET. I believe Visual Studio .NET 2003 had an add-on pack for Windows CE, and probably was meant for Windows CE .NET.
Anyway, that’s not the half of it. Almost every platform has an SDK you have to download for it.
Why do I mention this? Well, eVc++ 3.0 & 4.0 are free downloads from Microsoft, IDE, SDKs and all. Recently Tigerdirect.ca unloaded some refurb’ed WinCe gadgets for like $140, so I was able to replace my broken one and of course the CPU was different and I spent all of last night and tonight trying to get everything loaded back onto the poor little thing. So now I have pocket Chess loaded on it and some language dictionaries and a Japanese word processor with Kanji dictionary and stuff.
There’s an even deeper level of Windows CE hell, however called “Platform Builder” which allows you to build ROM images of the OS and such. I’m glad I’ve been mostly a good boy in this life and haven’t had the pleasure of that one yet.
All the WinCe stuff you can stand
So last Thursday Microsoft had a marketing orgy to “announce” that they will be shipping the Xbox 360 .. sometime later this year, probably before the holiday season.
Lots of technical info that had been floating around was finally, concretely confirmed, causing many rumour sites to close their “Xbox 360 rumours” sections.
The ‘360 will have 3 “G5-based” CPUs running at 3.5 GHz.
A nice trick, given that Apple’s fastest G5 runs at 2.7 GHz.
But then again, Apple is shipping hardware *now*.
Maybe Macs will be over 3 GHz by the end of the year?
It was also confirmed that the new Xbox will still be able to play that vast library of existing games (which has to be more than 1/4 the size of the Playstation 2’s).
I can hear the kids pleading for this thing already.
Hm, trying out a Technorati
If you can’t read the title of this post, it’s because it’s in Unicode! :-)
The most recent release of QuickSilver
has an all-Unicode name, which is interesting because in Terminal it doesn’t show up.
It’s just “Quicksilver.app”.
So somewhere in one of its plists (Property List, just an XML file) is the magic that sets its name.
if you know, leave a comment!
I ran across some interesting Mac-oriented blogs while Googling around today:
Some interesting stuff in there, especially about the recently-released new version of Mac OS X, “Tiger”, a.k.a. 10.4.
Good post at All Forces about
using Jabber gateways to acces MSN, Yahoo etc via iChat.
I’ve set it up and it seems to work. I used a Canadian server, nureality.ca, to set up my Jabber account.
Its Yahoo gateway seems down at the moment, though.
If you’ve got a custom kernel, getting the drivers installed for X to run properly under Linux can be a challenge. Start here to get the drivers: Drivers
Things you’ll be doing a lot:
Restarting X: telinit 3 to bring it down, telinit 5 to bring it up.
ALT-F7 is your X window, CTRL-ALT-F1 is a nice console terminal.
sh NVIDIA-Linux-x86-1.0-7174-pkg1.run gets you started
/usr/share/doc/NV*/README for details after that.
That document is huge, but you can text search it for the things that apply to your installation. Everything from multiple monitors to screen resolutions (controlled in /etc/X11/xorg.conf) is described in there. One of the key things in there is the command to extract the archive without deleting or running it. This allows you to examine the shell scripts they run in case you get weird errors, viewable in the log file they point you to. Basically, the shell script is going to ask you a bunch of things, bark at you, and then try and link the driver in as a module. This step can bring down your whole linux box when you next reboot it, until you force a runlevel=3 at grub to bypass the loading of a broken graphics driver link up (which of course there is no error message for). Let’s hope that doesn’t happen to you. Search here on TekTok for my previous fun with that.
The key to success is having a symbolic link in /usr/src called “linux” that points to your working linux kernel source tree, also hopefully installed in that directory. This kernel better be 188.8.131.52 or later.
Well that’s about it. Beyond that, happy RTFMing in /usr/share/doc/NV* !
that the new AMD Athlon 64 X2 4800+ (dual core CPU) has a better multi-core architecture than that of Intel, because when AMD designed the Athlon 64, they included multi-core in the initial design.
AMD engineers kept in mind the future dual-core designs when they started working on the AMD64 architecture already. Therefore, dual-core Athlon 64 X2 processors managed to avoid a few bottlenecks. Firstly, far not all the resources are duplicated in the new AMD processors. Although each of the two Athlon 64 X2 cores features its own set of execution units and individual L2 cache memory, the memory controller and the Hyper-Transport controller are the same for both cores. The two cores communicate with the shared resources via the special Crossbar-switch and System Request Queue. The communication between the cores is organized on the same level that is why cache coherency issues can be resolved without loading the system bus and the memory bus.
The thing is that Intel simply placed two Prescott cores into a single chip. In this case, the CPU has no special mechanisms for communication between the cores. In other words, the Smithfield cores communicate (to solve the cache coherency problems, for instance) via a system bus, just like the two CPUs in dual-processor Xeon based systems. As a result, the system bus is also shared by the processor cores when they work with the memory, which leads to higher latencies when both cores have to address the system memory.
It’s a pretty good writeup, even with X-bit’s usual, somewhat-broken English.
Found out about this via the MacCast forums
Apple is offering a limited time $100 discount
. In conjunction with the educational discount, you get the following prices:
Wow! Anyone know a student (in the US only, alas) who could buy a $379 Mac Mini for us? :-)