They can choose to buy a camera which doesn't use SD cards. There are plenty of competing formats around. Sony would be more than happy for you to buy a Memory Stick using camera.
Unfortunately, Memory Stick XC also uses exFAT as its filesystem. See the exFAT (or Memory Stick) pages. Those (SD and Memory Stick) seem to be the main formats at the moment.
The sad thing is, that exFAT is being patented. That means that Linux users will either have to be lucky enough to live in that shrinking part of the world where software patents are not allowed, or consult their lawyer before connecting their camera to their computer.
That's the same situation we have now with NTFS-3g and portable disks, really. Doesn't seem to have stopped people. Though to be fair, Microsoft could well be more aggressive about licensing exFAT since no-one is going to want to implement NTFS on a camera anyway.
What exactly is evil? Firstly, they haven't created a standard. If they had then surely they would have published the specifications somewhere. exFAT is a proprietry file format.
I don't know if they expect everyone to use it, although they may hope that everyone uses it.
Everything that wants to SDXC will have to use exFAT. It's part of that standard. This is going to be inconvenient for anyone who wants to use their shiny new camera/camcorder on a Mac or linux netbook or someone else's XP machine.
Embedded development and bootstrapping is the last bastion of necessity in assembly.
Any other use is likely for obfuscation, academia or pride.
About this time last year I was told to implement (in a C++ app) something not unlike the IMPORT command in VB. In other words, it allows you to call an arbitrary DLL function from a script language in our application.
Since we do not know at compile-time how many parameters are going to be passed to it, the only way I could think of doing this was to manually construct the stack into the required calling convention using PUSH instructions and do JMP EAX to call the function.
It took about 10-20 lines of assembler. I then had to do a couple of alternative implementations to support win32, elf32, win64, elf64 and win32 on ARM for the PDA version, but since there wasn't much code involved, the whole exercise took about a week from nothing to fully working.
Maybe there is a way to do this in C++ without resorting to assembler, and without requiring the called module to have a predefined interface, but I'm damned if I can think of one. To be fair, it is the only assembler module in the entire program.
When developing software for them? Lots. Also, don't underestimate the ability of WM6 to shit itself and require a reset to recover.
As for the G1, I find it tends to eat power rather more than I'd like when it's in standby. I have one that I use... basically for the purpose Chrome is designed for. It's mostly used as a pocket browser with a few other fancy doodads. For that? I'd be happy to leave it off until I need it, but like I say, it takes most of a minute to boot so I keep it in airplane mode most of the time and top it up once a week. If it could be booted in 7 seconds I would be a happy bunny.
I have another G1 that I use for voice, that needs to be charged more regularly. If you forget it'll go dead and then it's reboot time.
I haven't seen a recent smartphone that is on (and I don't mean, "displays something", I mean "fully usable") within 7 seconds.
This is exactly what I was going to say.
My G1 takes 50 seconds from power off to running, WM5/6 and Symbian take similar amounts of time (I don't have any to measure as I'm not at work) - I'm pretty sure some Nokias I used to use were more than a minute to run up when they had to be rebooted.
I haven't tried the iPhone.
Crosstalk is also improved if you use noise reduction. I record on 1/2" 8-track using DBX and the difference is quite significant. I've not used Dolby though so I can't really comment on that, but given that Dolby is/was the standard for 2" 24-track I'd be surprised if it didn't have a similar effect.
You're assuming he stuck them together like this: [_ _]
If it only read the number on the incoming edge, you might be able to attach them like this: [_ [_
Even if it didn't add them together and ignored the $1, you would still get $40 at a cost of $21.
I get this result on MacOS also. By the looks of it they're trying to play the MP4 files directly, which will not work because AFAIK Firefox only plays OGV format. They claim it works on the latest firefox - I don't know if they're thinking of the 3.6 series or something...
Depends on the version of the OS and policy of the device maker, I think.
A few years back I was developing against a Nokia E61 which ran S60r3 (i.e. Symbian 9) and it could only run signed binaries, which made testing on real hardware a nightmare.
My understanding was that they got tough with this in version 9 - earlier versions (like the S80 communicator I had before) would happily run unsigned apps.
Warehouses routinely use three or four sensors to maintain a 3D image of every stored item's position and tag#. Those sensors, for thousands of cubic meters, are each about a meter long, or smaller.
That's something I'd have to look into - I've been dealing with PDAs that have an RFID engine in them, this is the sort of system you'd usually have in a hand-held device, and the range is abysmal.
I'm not yet convinced you would be able to do anything with a warehouse-like range outside of a static installation...
Pretty much all the RFID systems I've played with have a range of about 5-10cm. For something like a 1 metre range I think you'll need a seriously huge antenna.
Your link sends me to a placeholder (1x1 "void.gif").
To me the Palm[sized] PC shell appeared vaguely similar to the Handheld PC shell, but it was stripped down with all the root windows stuck at full screen and no widgets to detach or minimize them. That was the distinction I was getting at.
...it has a few screenshots of the thing. See around pages 5 and 18.
Windows Mobile definitely does the fullscreen-only thing, and that seems to be one of the key differences from the bare CE.Net shell.
Anyway, if there's still a viable Handheld PC code base in active development at Microsoft it seems really strange that they're not pushing it on linux-friendly netbook makers.
I imagine they will if the ARM/Linux platform takes off, but like I said earlier, it looks like Windows 95 and doesn't work with any off-the-shelf apps or USB devices more complex than a memory stick (if that).
If Linux is enough to make people return the devices, even with OpenOffice etc installed, Windows CE certainly will. And that might be one reason they aren't actively pushing it.
...start menu at the bottom in the left corner, and a taskbar. I think this shot is running in an emulator rather than a physical device, though.
Interesting. I really thought Microsoft had killed the Windows-CE-based Handheld PC. I've seen devices described that way since, but they've all been NT-based. It's an ARM, BTW. Does anyone still use MIPS in handhelds?
Ah. There is conflicting information about the CNMbook CPU. Some say ARM, some say MIPS.
My guess would be that they switched in later models. They have Linux and CE.NET versions of the thing, so they may have had an earlier MIPS/Linux one or something. Just a guess, though.
As for MIPS in CE handhelds, that certainly seems to be dead. WM2003 and onwards are only for ARM, though there are also the occasional THUMB-only devices like the Casio IT500 (which yes, used the Win95-alike shell).
I don't honestly know if MIPS is supported for CE.NET itself or not.
Those devices have a PDA form factor, they're all using either a custom shell or something based on the Pocket PC shell. They're not using the Handheld PC shell that was used in things like the Thinkpad z50 or Jornada 720.
Okay, it took 10 years but this conversation has finally piqued my interest enough to finally get an account;)
We may possibly be talking cross-purposes, but these manufacturers aren't using a per-vendor custom shell because they're all the same. They most certainly aren't shipping Windows Mobile either.
I've never used Platform Builder so I don't know for sure, but as I understand it, a stock CE build (branded as CE.Net since v4) ships with a default shell based on the old Handheld PC one and only slightly updated. WM6 is just the CE.Net core with a prettier shell.
FWIW, you might want to look up the CNMbook, since that actually is a CE5.NET netbook (based on a MIPS core, I think).
Smartphones and some industrial devices like the Motorola MCxx generally ship with WM5/6, but in many cases (for the Industrial units) they give you a choice of the CE.Net shell and Windows Mobile. Intermec actually sent me a survey asking if their customers preferred CE.Net or Windows Mobile.
So at the end of the day, yes, HandheldPC itself is dead and buried, but there are still a number of devices shipping with the same basic shell, albeit on a CE5 kernel rather than CE2.11.
Slashdot Mirror
They can choose to buy a camera which doesn't use SD cards. There are plenty of competing formats around. Sony would be more than happy for you to buy a Memory Stick using camera.
Unfortunately, Memory Stick XC also uses exFAT as its filesystem. See the exFAT (or Memory Stick) pages. Those (SD and Memory Stick) seem to be the main formats at the moment.
Unless Microsoft somehow coerced the association to select exFAT, I consider this to be a bad move by the association rather than Microsoft.
That may be. It has the same net result though.
The sad thing is, that exFAT is being patented. That means that Linux users will either have to be lucky enough to live in that shrinking part of the world where software patents are not allowed, or consult their lawyer before connecting their camera to their computer.
That's the same situation we have now with NTFS-3g and portable disks, really. Doesn't seem to have stopped people. Though to be fair, Microsoft could well be more aggressive about licensing exFAT since no-one is going to want to implement NTFS on a camera anyway.
Ugh. Make that "Everything that wants to use SDXC."
What exactly is evil? Firstly, they haven't created a standard. If they had then surely they would have published the specifications somewhere. exFAT is a proprietry file format.
I don't know if they expect everyone to use it, although they may hope that everyone uses it.
Everything that wants to SDXC will have to use exFAT. It's part of that standard. This is going to be inconvenient for anyone who wants to use their shiny new camera/camcorder on a Mac or linux netbook or someone else's XP machine.
Embedded development and bootstrapping is the last bastion of necessity in assembly.
Any other use is likely for obfuscation, academia or pride.
About this time last year I was told to implement (in a C++ app) something not unlike the IMPORT command in VB. In other words, it allows you to call an arbitrary DLL function from a script language in our application.
Since we do not know at compile-time how many parameters are going to be passed to it, the only way I could think of doing this was to manually construct the stack into the required calling convention using PUSH instructions and do JMP EAX to call the function.
It took about 10-20 lines of assembler. I then had to do a couple of alternative implementations to support win32, elf32, win64, elf64 and win32 on ARM for the PDA version, but since there wasn't much code involved, the whole exercise took about a week from nothing to fully working.
Maybe there is a way to do this in C++ without resorting to assembler, and without requiring the called module to have a predefined interface, but I'm damned if I can think of one. To be fair, it is the only assembler module in the entire program.
It makes one wonder what he smokes...
1960s Dr. Who by the looks of things. Man, I'd forgotten about those...
How often do you reboot your phone?
When developing software for them? Lots. Also, don't underestimate the ability of WM6 to shit itself and require a reset to recover.
As for the G1, I find it tends to eat power rather more than I'd like when it's in standby. I have one that I use... basically for the purpose Chrome is designed for. It's mostly used as a pocket browser with a few other fancy doodads. For that? I'd be happy to leave it off until I need it, but like I say, it takes most of a minute to boot so I keep it in airplane mode most of the time and top it up once a week. If it could be booted in 7 seconds I would be a happy bunny.
I have another G1 that I use for voice, that needs to be charged more regularly. If you forget it'll go dead and then it's reboot time.
I haven't seen a recent smartphone that is on (and I don't mean, "displays something", I mean "fully usable") within 7 seconds.
This is exactly what I was going to say. My G1 takes 50 seconds from power off to running, WM5/6 and Symbian take similar amounts of time (I don't have any to measure as I'm not at work) - I'm pretty sure some Nokias I used to use were more than a minute to run up when they had to be rebooted. I haven't tried the iPhone.
Crosstalk is also improved if you use noise reduction. I record on 1/2" 8-track using DBX and the difference is quite significant. I've not used Dolby though so I can't really comment on that, but given that Dolby is/was the standard for 2" 24-track I'd be surprised if it didn't have a similar effect.
You're assuming he stuck them together like this: [_ _] If it only read the number on the incoming edge, you might be able to attach them like this: [_ [_ Even if it didn't add them together and ignored the $1, you would still get $40 at a cost of $21.
I get this result on MacOS also. By the looks of it they're trying to play the MP4 files directly, which will not work because AFAIK Firefox only plays OGV format. They claim it works on the latest firefox - I don't know if they're thinking of the 3.6 series or something...
Depends on the version of the OS and policy of the device maker, I think. A few years back I was developing against a Nokia E61 which ran S60r3 (i.e. Symbian 9) and it could only run signed binaries, which made testing on real hardware a nightmare. My understanding was that they got tough with this in version 9 - earlier versions (like the S80 communicator I had before) would happily run unsigned apps.
Warehouses routinely use three or four sensors to maintain a 3D image of every stored item's position and tag#. Those sensors, for thousands of cubic meters, are each about a meter long, or smaller.
That's something I'd have to look into - I've been dealing with PDAs that have an RFID engine in them, this is the sort of system you'd usually have in a hand-held device, and the range is abysmal. I'm not yet convinced you would be able to do anything with a warehouse-like range outside of a static installation...
Pretty much all the RFID systems I've played with have a range of about 5-10cm. For something like a 1 metre range I think you'll need a seriously huge antenna.
What the hell is a palm?
That PDA-looking thing at the top of the page. (I'm assuming you're being serious). The base resolution was 160x160.
Your link sends me to a placeholder (1x1 "void.gif").
To me the Palm[sized] PC shell appeared vaguely similar to the Handheld PC shell, but it was stripped down with all the root windows stuck at full screen and no widgets to detach or minimize them. That was the distinction I was getting at.
Try this: http://www.bluechiptechnology.co.uk/files/CE6UProgrammersUserGuide.pdf
...it has a few screenshots of the thing. See around pages 5 and 18.
Windows Mobile definitely does the fullscreen-only thing, and that seems to be one of the key differences from the bare CE.Net shell.
Anyway, if there's still a viable Handheld PC code base in active development at Microsoft it seems really strange that they're not pushing it on linux-friendly netbook makers.
I imagine they will if the ARM/Linux platform takes off, but like I said earlier, it looks like Windows 95 and doesn't work with any off-the-shelf apps or USB devices more complex than a memory stick (if that).
If Linux is enough to make people return the devices, even with OpenOffice etc installed, Windows CE certainly will. And that might be one reason they aren't actively pushing it.
It sure looks like the Palm-PC/Palm-sized PC/Pocket PC shell, not the Handheld-PC one.
Here's an example, if you're curious:
http://mylostblog.altervista.org/i/windows-ce-6-mlb.png
...start menu at the bottom in the left corner, and a taskbar. I think this shot is running in an emulator rather than a physical device, though.
Interesting. I really thought Microsoft had killed the Windows-CE-based Handheld PC. I've seen devices described that way since, but they've all been NT-based. It's an ARM, BTW. Does anyone still use MIPS in handhelds?
Ah. There is conflicting information about the CNMbook CPU. Some say ARM, some say MIPS.
My guess would be that they switched in later models. They have Linux and CE.NET versions of the thing, so they may have had an earlier MIPS/Linux one or something. Just a guess, though.
As for MIPS in CE handhelds, that certainly seems to be dead. WM2003 and onwards are only for ARM, though there are also the occasional THUMB-only devices like the Casio IT500 (which yes, used the Win95-alike shell).
I don't honestly know if MIPS is supported for CE.NET itself or not.
I think we're talking at cross purposes.
Those devices have a PDA form factor, they're all using either a custom shell or something based on the Pocket PC shell. They're not using the Handheld PC shell that was used in things like the Thinkpad z50 or Jornada 720.
Okay, it took 10 years but this conversation has finally piqued my interest enough to finally get an account ;)
We may possibly be talking cross-purposes, but these manufacturers aren't using a per-vendor custom shell because they're all the same. They most certainly aren't shipping Windows Mobile either.
I've never used Platform Builder so I don't know for sure, but as I understand it, a stock CE build (branded as CE.Net since v4) ships with a default shell based on the old Handheld PC one and only slightly updated. WM6 is just the CE.Net core with a prettier shell.
FWIW, you might want to look up the CNMbook, since that actually is a CE5.NET netbook (based on a MIPS core, I think).
Smartphones and some industrial devices like the Motorola MCxx generally ship with WM5/6, but in many cases (for the Industrial units) they give you a choice of the CE.Net shell and Windows Mobile. Intermec actually sent me a survey asking if their customers preferred CE.Net or Windows Mobile.
So at the end of the day, yes, HandheldPC itself is dead and buried, but there are still a number of devices shipping with the same basic shell, albeit on a CE5 kernel rather than CE2.11.