Hmmm... seems like you just took a chunk of code completely out of context. The ASSERT above can be found in four or five places in that file in code paths that convert a GUID struct to a string via a call to StringFromGUID2. Given that GUIDs have a fixed definition, and every piece of COM based software ever written relies on that definition, it's safe to assume that this isn't going to change. The assert is in place simply to detect a condition which should never be hit unless the function definition for StringFromGUID2 changes. The buffer allocated will always have enough space for a GUID.
You are correct, eVC4 supports native code on WM2003 (and any device built around Windows CE 4.0 through Windows CE 5.0). Visual Studio 2003 supports the.NET Compact Framework v1, and does not support any kind of native code development on devices. Visual Studio 2005 supports the.NET Compact Framework v2 for devices that support it, v1 for Smartphones (they can't upgrade the framework version in ROM). Visual Studio 2005 supports native development on Windows CE 5.0 devices (WM 5.0) and beyond. It does tend to be a bit confusing.
You should look at VS 2005 Beta 2. There should be an option called "code definition window" that shows you the implementation of the function you are calling. It's very useful.
It's highly unlikely that this would happen. The most obvious argument against this that I see is that although the CPU cores may share some common ancestry, what really drives console games is the fact that you can squeeze every tiny bit of performance out of the machine by coding directly to the hardware, i.e. video and sound. If the memory architecture, etc. is different, then the perf is going to be totally different on two different platforms. Just my 2 cents. Cheers!
engywook is correct, and any reasonable build system will already be doing this. I work in a team that builds binaries for ~11 different CPU types, and we consume binaries and build systems from numerous other teams. All of them use some form of $(OutputDir) = $(Platform incl. CPU)\$(Configuration e.g. Debug, Release, etc.)
Uh, haven't you ever seen all the stoplights go red in an intersection to allow emergency vehicles to pass through quickly? N/S XOR E/W is a convention, not a hard and fast law. It would be trivial to put red light cameras on these intersections to nail those who run the light. As long as the threshhold is reasonably set (say, 10mph over the limit), I don't really have a problem with this.
As someone who works with portable technology all day, the next great technological leap in this area that I see is going to be making devices and technologies work together with better software.
This, of course, has been promised for many years, but we've finally got a lot of the technology base required to make it seamless. On the way to a soccer game with two coworkers, I can now receive my office email on my smartphone, check the traffic conditions and decide which route to take.
In a year or two (or three), I'd expect that new cars would automatically detect that I've got a bluetooth phone, and use a standardized api to communicate back and forth. If a phone call comes in, the radio will turn itself down, and if I pull over to answer it, the radio will function as a speakerphone. What about if I have location services on my phone (and these are coming), and a GPRS net connection? I should be able to use voice command to tell the phone to download directions from here to X, and then playback those directions over the radio.
My cellphone already tracks my location, what if that also functioned like instant messaging apps, and let me know when one of my friends was online and somewhere nearby? I'm headed to the gym, and so are Bob and Sue. Open a quick push to talk session, and ask them if they want to meet up by the weight bench?
I head home, and now my cellphone functions as a remote control for all the bluetooth enabled components in my stereo and it also recognizes that I'm home, and automatically sets up call forwarding to my home number, which is voice over ip based. I want to watch a movie stored on my pc, but that should be transparent to me, because it's all wirelessly connected.
It's pretty easy to go on forever with scenarios like these, all of which are possible today, but only with custom written software. In a few years, this should all be happening automatically, or with a few clicks and button presses.
So, I'm going to argue against the seemingly overwhelming majority of people out there about voting machines.
Yes, there are issues. Are the issues any worse than what can/has been done in the past with non-electronic voting? Probably not. I think that Florida proved that you can tamper with the old system just as well as an electronic one.
Eventually what voting comes down to is trusting that the people who run the system are honest. If you have dishonest people anywhere in the chain; you're going to get bogus results. The only solution that I can see to this issue is that the process must become more open.
1) Diebold needs to modify the machines to produce a printed slip that shows the party X voted for. X is then responsible for ensuring that the slip makes it into the collection basket. Bar codes can be used to correlate votes in the machine and votes on paper, and verify that they match. Because the electronic vote must match the paper vote, and because the user can verify the paper vote themselves, it becomes harder to cheat.
2) Make the vote counting process open. If anyone wants to, let them watch votes being counted. Canada does this, why not? Votes are counted to verify election results. In the event of a discrepancy, the paper votes would be used. The electronic tallies would be used for "quick" results.
I find it much easier to carry around a USB keychain drive. It's smaller, holds more data, tougher, and is compatible with virtually every machine that I care about. If the machine doesn't support the USB drive, then odds are good that it's connected to the net. Failing that, I would resort to CDs before floppies as I suspect you'd damage a floppy before a CD in a small jewel case.
Uhhh... not so fast there. Take a look at the implementations of Java on mobile devices. See anything missing? Hint: they only added floating point support in v1.1. Every vendor has a different implementation of the standard, and different interfaces/extensions for their own hardware.
No you fool, don't tell them yet! This is all part of my incredibly ingenious plan to get all the script kiddies and spammers in the world to follow these instructions to "enlarge" their three inch hard disks and corrupt all of their data in the process. Nobody remotely knowledgeable about computers would ever believe this, and nobody who knows nothing about computers would possibly attempt to do this. Who does this leave? Yes, the script kiddies and spammers. Now it's back to Plan B, sharks with frickin' laser beams on their heads.
I never could get into political non-fiction, but I'm really enjoying a political fiction series right now. It's about this bumbling guy, who's dad was president, and manages to get himself elected president as well, despite having no appreciable talent. The election article is really fantastic, but totally unbelievable. I mean, who would allow shady election results from a state run by the guy's brother? But it just gets better, he gets them involved in an oil war to distract the public from a failing economy and his overall failed attempt to catch a notorious criminal (there's also a subplot about how he's trying to avenge his dad). It's really funny, because he declares the war over too early... oh well, I'd better stop before I ruin the ending:)
Okay, you're wrong. eVC4 is freely available as well, why not check the website next time? Mobile Developer Downloads. You will also need to download SP2 if you plan on developing against the PPC 2003 SDK.
Slashdot Mirror
Hmmm... seems like you just took a chunk of code completely out of context. The ASSERT above can be found in four or five places in that file in code paths that convert a GUID struct to a string via a call to StringFromGUID2. Given that GUIDs have a fixed definition, and every piece of COM based software ever written relies on that definition, it's safe to assume that this isn't going to change. The assert is in place simply to detect a condition which should never be hit unless the function definition for StringFromGUID2 changes. The buffer allocated will always have enough space for a GUID.
You are correct, eVC4 supports native code on WM2003 (and any device built around Windows CE 4.0 through Windows CE 5.0). Visual Studio 2003 supports the .NET Compact Framework v1, and does not support any kind of native code development on devices. Visual Studio 2005 supports the .NET Compact Framework v2 for devices that support it, v1 for Smartphones (they can't upgrade the framework version in ROM). Visual Studio 2005 supports native development on Windows CE 5.0 devices (WM 5.0) and beyond. It does tend to be a bit confusing.
You should look at VS 2005 Beta 2. There should be an option called "code definition window" that shows you the implementation of the function you are calling. It's very useful.
It's highly unlikely that this would happen. The most obvious argument against this that I see is that although the CPU cores may share some common ancestry, what really drives console games is the fact that you can squeeze every tiny bit of performance out of the machine by coding directly to the hardware, i.e. video and sound. If the memory architecture, etc. is different, then the perf is going to be totally different on two different platforms. Just my 2 cents. Cheers!
engywook is correct, and any reasonable build system will already be doing this. I work in a team that builds binaries for ~11 different CPU types, and we consume binaries and build systems from numerous other teams. All of them use some form of $(OutputDir) = $(Platform incl. CPU)\$(Configuration e.g. Debug, Release, etc.)
Actually, Simon Garfunkle is the near prime public key for Simson Garfinkel. What's the current Slashdot karma factor for incredibly bad puns?
Uh, haven't you ever seen all the stoplights go red in an intersection to allow emergency vehicles to pass through quickly? N/S XOR E/W is a convention, not a hard and fast law. It would be trivial to put red light cameras on these intersections to nail those who run the light. As long as the threshhold is reasonably set (say, 10mph over the limit), I don't really have a problem with this.
As someone who works with portable technology all day, the next great technological leap in this area that I see is going to be making devices and technologies work together with better software.
This, of course, has been promised for many years, but we've finally got a lot of the technology base required to make it seamless. On the way to a soccer game with two coworkers, I can now receive my office email on my smartphone, check the traffic conditions and decide which route to take.
In a year or two (or three), I'd expect that new cars would automatically detect that I've got a bluetooth phone, and use a standardized api to communicate back and forth. If a phone call comes in, the radio will turn itself down, and if I pull over to answer it, the radio will function as a speakerphone. What about if I have location services on my phone (and these are coming), and a GPRS net connection? I should be able to use voice command to tell the phone to download directions from here to X, and then playback those directions over the radio.
My cellphone already tracks my location, what if that also functioned like instant messaging apps, and let me know when one of my friends was online and somewhere nearby? I'm headed to the gym, and so are Bob and Sue. Open a quick push to talk session, and ask them if they want to meet up by the weight bench?
I head home, and now my cellphone functions as a remote control for all the bluetooth enabled components in my stereo and it also recognizes that I'm home, and automatically sets up call forwarding to my home number, which is voice over ip based. I want to watch a movie stored on my pc, but that should be transparent to me, because it's all wirelessly connected.
It's pretty easy to go on forever with scenarios like these, all of which are possible today, but only with custom written software. In a few years, this should all be happening automatically, or with a few clicks and button presses.
So, I'm going to argue against the seemingly overwhelming majority of people out there about voting machines.
:)
Yes, there are issues. Are the issues any worse than what can/has been done in the past with non-electronic voting? Probably not. I think that Florida proved that you can tamper with the old system just as well as an electronic one.
Eventually what voting comes down to is trusting that the people who run the system are honest. If you have dishonest people anywhere in the chain; you're going to get bogus results. The only solution that I can see to this issue is that the process must become more open.
1) Diebold needs to modify the machines to produce a printed slip that shows the party X voted for. X is then responsible for ensuring that the slip makes it into the collection basket. Bar codes can be used to correlate votes in the machine and votes on paper, and verify that they match. Because the electronic vote must match the paper vote, and because the user can verify the paper vote themselves, it becomes harder to cheat.
2) Make the vote counting process open. If anyone wants to, let them watch votes being counted. Canada does this, why not? Votes are counted to verify election results. In the event of a discrepancy, the paper votes would be used. The electronic tallies would be used for "quick" results.
Well, it's an idea, anyways
I find it much easier to carry around a USB keychain drive. It's smaller, holds more data, tougher, and is compatible with virtually every machine that I care about. If the machine doesn't support the USB drive, then odds are good that it's connected to the net. Failing that, I would resort to CDs before floppies as I suspect you'd damage a floppy before a CD in a small jewel case.
Uhhh... not so fast there. Take a look at the implementations of Java on mobile devices. See anything missing? Hint: they only added floating point support in v1.1. Every vendor has a different implementation of the standard, and different interfaces/extensions for their own hardware.
No you fool, don't tell them yet! This is all part of my incredibly ingenious plan to get all the script kiddies and spammers in the world to follow these instructions to "enlarge" their three inch hard disks and corrupt all of their data in the process. Nobody remotely knowledgeable about computers would ever believe this, and nobody who knows nothing about computers would possibly attempt to do this. Who does this leave? Yes, the script kiddies and spammers. Now it's back to Plan B, sharks with frickin' laser beams on their heads.
I never could get into political non-fiction, but I'm really enjoying a political fiction series right now. It's about this bumbling guy, who's dad was president, and manages to get himself elected president as well, despite having no appreciable talent. The election article is really fantastic, but totally unbelievable. I mean, who would allow shady election results from a state run by the guy's brother? But it just gets better, he gets them involved in an oil war to distract the public from a failing economy and his overall failed attempt to catch a notorious criminal (there's also a subplot about how he's trying to avenge his dad). It's really funny, because he declares the war over too early... oh well, I'd better stop before I ruin the ending :)
Yeah, there's an update, but it hasn't been publicized very well. Look at the FAQ and download pages to get an updated client. HTH
Okay, you're wrong. eVC4 is freely available as well, why not check the website next time? Mobile Developer Downloads. You will also need to download SP2 if you plan on developing against the PPC 2003 SDK.