Sounds like the real answer to this problem is an improved USB to serial dongle. If this is a serious problem for electronics engineers, they are the perfect people to fix it. Whatever the problem with the USB to serial interface is, fix it. Then sell your improved serial port adapter for $100. Profit!
The problem is not the hardware. It is the software stack in the middle which is necessary to implement USB.
If only there was a way to put, say, a 16550A chip on the processor data bus and hook it into the port I/O logic... (/sarcasm)
I work with embedded software. Chip designs are often 20 years old. So are the software development tools.
Software designed for Windows 3.1, or even DOS 5.0, will still run under XP. They will not run under Windows 8, or even Windows 7 (64-bit, I have to get my hands on a Windows 7 32-bit disk and see if it works).
Moreover, on chips that old you talk to them via serial (either RS232 or RS485). To do it properly, this MUST be done using a real serial port. USB to serial dongles need not apply. This means old hardware. Which means they do not have the horsepower to run Windows 7 / Windows 8.
I've played with some VM's but there is a problem -- limited access to the actual system hard drive. So I either have 99% of my system in the VM (so all projects area availble), which means I spend all my time in the VM (and am effectively running XP anyway), or multiple small VM's, which limits access to different projects for code sharing...
The compilers / tools are written for the biggest section of the market. This means Windows.
Moreover, many of the tools were written years ago. This means Windows 95 compatibility.
So, I'm using Windows. Windows XP to be exact, and dread having my computer die on me -
I'm not sure I can get many of the old tools running under Windows 7.
Damn, I'm old. I remember personal computers before IBM threw their hat in the ring. I lusted after microprocessors and blinking lights in an 8-bit world.
I'm so old I actually bought one of the SCP board sets (my first computer purchase! I could not resist the lure of 16-bit power), an S-100 mainframe kit, and started soldering.
My system came with DOS version 0.10, serial number 11 on an 8" 256K soft sector floppy (for my Cromemco 4FDC running a Persci 277 dual floppy drive). And I still have the assembler / linker / ROM monitor source on my hard drive (anyone else remember the trick 6-byte ASCII hex conversion?)
What's really amazing is that the skills I used for this are what I use every day in my job (embedded software for industrial controllers). I never learned Windows / Linux programming...
What if an OSS project comes up with a technique or technology first? What if an OSS project comes up with an idea, but never pursues a patent; then a company comes along later and attempts to patents the same idea not knowing the OSS project got there first?
When the company attempts to assert patent rights over the OSS project, can the OSS project invalidate the patent by proving they came up with the idea first?
Having prior art available can help, but the USPTO is so broken that it wouldn't even slow the leeches down.
The USPTO is completely overworked (everyone trying to patent everything), the patent examiners do not have any real knowledge of software prior art nor access to a good database (they basically search the patent database), and rely on the "good faith" of the patent submitter to list prior art. Add to that the USPTO's system that they only get paid for ACCEPTED patents, and you get our current mess.
Moreover, our system is a "first to invent", which means the first person to come up with the idea can get a patent, even if someone else beats them to the marketplace. However, you have to prove that you were the first to invent, and have a window of 1 year from the first public demonstration of the invention. So, practically this means that unless you have documentation that you invented something at least 1 year before the other person's patent submission, you can still lose out.
Once a patent is granted, there is a presumption that the patent is valid, which means that challenging the patent means an uphill battle in court to show that the patent should never have been granted in the first place (publically known prior art, witholding prior art on patent application, etc).
Also, two fundamentals parts of the patentability test are being ignored:
1) obviousness
(which everyone talks about) and
2) The patent submission be sufficiently detailed to show a person with ordinary skills in the field to create the patented item.
Which is completely lacking in software patents. The typical software patent just says "'X' can be done on a computer!" and has NO DETAIL WHATSOEVER as how to accomplish 'X'.
And, it's been a while since I heard about it (and can't find a link right now), but there was a backdoor effort to change the US patent system from "first to invent" to "first to file".
This would mean that someone could come up with a neat piece of software, post it in sourceforge, and have someone come along and patent it. They did not invent it first. They did not invent it AT ALL. But they would have a valid patent and could shutdown / collect royalties from anyone.
Oddly enough, Microsoft was in favor of this legislation.
I used GCC with an IAPX420 (an ARM) as the target.
While the x86 architecture may allow for pointers to arbitrary memory locations, other CPUs may not.
In this case, GCC used a pointer to a 16-byte memory location, which according to the CPU architecture had to point to an even boundary. Hence, the problem.
Consider the data:
char m1[7] = { 1, 2, 3, 4, 5, 6, 7 };
char m2[7] = { 8, 9, 10, 11, 12, 13, 14 };/* one of m1, m2 will be at an odd address */
struct z { u_int16_t a; u_int16_t b[2]; }__attribute__((packed));
Then,
printf("m1: %04x ?= %04x\n",((struct z *)m1)->b[0],*((struct z *)m1)->b);
printf("m2: %04x ?= %04x\n",((struct z *)m2)->b[0],*((struct z *)m2)->b);
According to section 3.2.2.1, prefix * and postfix [0] are identical.
However, according to 3.3.4, the affect of the pointer conversion may yield an invalid pointer, due to the (potentially) stricter memory alignment of the new type.
1) I survived a slashdotting! Yah!! (at least it wasn't the front page!)
2) Where I expect the source code to show up most often is in someone's compiler class homework (unattributed, of course...)
3) People have been asking "what's the use of an old compiler"? As I mentioned on the website, it's small enough so that a noobie (like me) can get their teeth into it. The code itself may never go anywhere, but the lessons learned will
be around for a long time.
FWIW, I am an (ex-)anti-virus author, and I actually looked at this patent.
First, the person who wrote the text should be shot... it's worded to be as confusing as possible, so that even an expert in the field can't readily tell what is being covered in the patent.
Next, from what I can tell, the patent seems to cover 3 main points (in various flavors, to come up with their 20 points):
1) We don't just scan for strings, we take into consieration what sort of virus it might be, and only scan in the appropriate place.
2) We have a "scripting language" that can direct the virus scan.
3) We can emulate a "virus target" and see if the virus goes for it.
All of these points were done years ago. The first two points were "state of the art" as of 1990. The product I worked on (name withheld for various reasons. Sorry about that...) was, at the time, unlike the other virus scanners out there. It used "precision scanning" in which the nature of the virus being scanned for was taken into account, and was scanned for ONLY AT THE LOCATION AT WHICH THE INFECTION WOULD OCCUR. This was a major differentiation from the "bulk scanners"
(i.e. run the entire file through a string filter that contains all virus signatures, and see if there are any matches. As a trivia note, "bulk scanners" are why all anti-virus scanners use encrypted (in some trivial way) virus signatures -- so that a virus scanner would not be identified as an infected file by another virus scanner, or even by itself!) that all other major anti-virus vendors used.
Also, the virus scanner I wrote included a scripting language so that users could add their own virus scan and remove definitions.
As for emulating a virus target and seeing if the virus "bites", that is also old hat. While a commercial product was never introduced, a lab prototype was publically demonstrated in 1996, in which files under examination were interpreted in a virtual 80x86 environment, including OS and file system, both to see if they did anything suspicious, and to see if they "tagged along" on "provocative" system calls.
And, yes, I still have my old code sitting around. It would be a pity if someone suddenly showed it to Symantec or the patent office...
Slashdot Mirror
and compare it to the disassembled code I have from years ago. I'm willing to bet the disassemblies have better comments.
The problem is not the hardware. It is the software stack in the middle which is necessary to implement USB.
If only there was a way to put, say, a 16550A chip on the processor data bus and hook it into the port I/O logic... (/sarcasm)
I work with embedded software. Chip designs are often 20 years old. So are the software development tools.
Software designed for Windows 3.1, or even DOS 5.0, will still run under XP. They will not run under Windows 8, or even Windows 7 (64-bit, I have to get my hands on a Windows 7 32-bit disk and see if it works).
Moreover, on chips that old you talk to them via serial (either RS232 or RS485). To do it properly, this MUST be done using a real serial port. USB to serial dongles need not apply. This means old hardware. Which means they do not have the horsepower to run Windows 7 / Windows 8.
I've played with some VM's but there is a problem -- limited access to the actual system hard drive. So I either have 99% of my system in the VM (so all projects area availble), which means I spend all my time in the VM (and am effectively running XP anyway), or multiple small VM's, which limits access to different projects for code sharing...
printf("Hello, World!\n");
more people should frequent reddit.com/r/datahoarder
Torrents only work if the data is available somewhere.
I write embedded code for a living.
The compilers / tools are written for the biggest section of the market. This means Windows.
Moreover, many of the tools were written years ago. This means Windows 95 compatibility.
So, I'm using Windows. Windows XP to be exact, and dread having my computer die on me -
I'm not sure I can get many of the old tools running under Windows 7.
They had to wait for the copyrights to expire...
OK, I'll admit it...
Damn, I'm old. I remember personal computers before IBM threw their hat in the ring. I lusted after microprocessors and blinking lights in an 8-bit world.
I'm so old I actually bought one of the SCP board sets (my first computer purchase! I could not resist the lure of 16-bit power), an S-100 mainframe kit, and started soldering.
My system came with DOS version 0.10, serial number 11 on an 8" 256K soft sector floppy (for my Cromemco 4FDC running a Persci 277 dual floppy drive). And I still have the assembler / linker / ROM monitor source on my hard drive (anyone else remember the trick 6-byte ASCII hex conversion?)
What's really amazing is that the skills I used for this are what I use every day in my job (embedded software for industrial controllers). I never learned Windows / Linux programming...
The $15 is not to "compensate Microsoft for its development efforts."
The $15 is an attempt to kill Android.
Failing that, they will at least have a huge pile of money to weep into...
I'm pretty sure the actual amount is $699
For those who really care -- Plato (emulated) is still online.
Cyber1
So, if I drink Fiji Water consistently, they will never be able to prove that I was anywhere near the crime scene?
COOL!
I work in embedded software (tiny little systems, not something like embedded Linux).
Software systems for some of these chips dates back to Windows 3.1.
There is insufficient support for this software in Vista / Windows 7.
Not to mention direct hardware access to system resources like RS232 ports (USB COMM ports
need not apply).
I'm surprised I haven't see this yet: http://xkcd.com/378/
$0.99 / song
Personally, I'll take 355/113.
The USPTO is completely overworked (everyone trying to patent everything), the patent examiners do not have any real knowledge of software prior art nor access to a good database (they basically search the patent database), and rely on the "good faith" of the patent submitter to list prior art. Add to that the USPTO's system that they only get paid for ACCEPTED patents, and you get our current mess.
Moreover, our system is a "first to invent", which means the first person to come up with the idea can get a patent, even if someone else beats them to the marketplace. However, you have to prove that you were the first to invent, and have a window of 1 year from the first public demonstration of the invention. So, practically this means that unless you have documentation that you invented something at least 1 year before the other person's patent submission, you can still lose out.
Once a patent is granted, there is a presumption that the patent is valid, which means that challenging the patent means an uphill battle in court to show that the patent should never have been granted in the first place (publically known prior art, witholding prior art on patent application, etc).
Also, two fundamentals parts of the patentability test are being ignored: (which everyone talks about) and Which is completely lacking in software patents. The typical software patent just says "'X' can be done on a computer!" and has NO DETAIL WHATSOEVER as how to accomplish 'X'.
And, it's been a while since I heard about it (and can't find a link right now), but there was a backdoor effort to change the US patent system from "first to invent" to "first to file".
This would mean that someone could come up with a neat piece of software, post it in sourceforge, and have someone come along and patent it. They did not invent it first. They did not invent it AT ALL. But they would have a valid patent and could shutdown / collect royalties from anyone. Oddly enough, Microsoft was in favor of this legislation.
Bill
As my foggy memory (and limited Google skills) serve, the Ipod was introduced
about 3 years ago (2003).
Would people have taken such a pronouncement as obviously true 3 years ago?
Why should it be given any more credence today?
But your average corporate attorney isn't the problem, he or she is simply a tool
They are tools, all right...
They are people, and therefore can and should be held responsible for their actions.
They can, at any time, say "That's evil, I won't do it." And leave.
But they don't, they are just as bad as the geedy bastards they work for, and should be held just a liable.
Bill
I used GCC with an IAPX420 (an ARM) as the target.
While the x86 architecture may allow for pointers to arbitrary memory locations, other CPUs may not.
In this case, GCC used a pointer to a 16-byte memory location, which according to the CPU architecture had to point to an even boundary. Hence, the problem.
Bill
This one recently came and bit me on the ass.
/* one of m1, m2 will be at an odd address */
Pointers and arrays are NOT interchangeable!
Consider the data:
char m1[7] = { 1, 2, 3, 4, 5, 6, 7 };
char m2[7] = { 8, 9, 10, 11, 12, 13, 14 };
struct z { u_int16_t a; u_int16_t b[2]; }__attribute__((packed));
Then,
printf("m1: %04x ?= %04x\n",((struct z *)m1)->b[0],*((struct z *)m1)->b);
printf("m2: %04x ?= %04x\n",((struct z *)m2)->b[0],*((struct z *)m2)->b);
According to section 3.2.2.1, prefix * and postfix [0] are identical.
However, according to 3.3.4, the affect of the pointer conversion may yield an invalid pointer, due to the (potentially) stricter memory alignment of the new type.
Bill
1) I survived a slashdotting! Yah!! (at least it wasn't the front page!)
2) Where I expect the source code to show up most often is in someone's compiler class homework (unattributed, of course...)
3) People have been asking "what's the use of an old compiler"? As I mentioned on the website, it's small enough so that a noobie (like me) can get their teeth into it. The code itself may never go anywhere, but the lessons learned will be around for a long time.
Bill
But we will have continuation of our beloved government!
Cheny will take his hand out of Bush'es ass and have his *OWN* presidency!
{bleah}
First, the person who wrote the text should be shot... it's worded to be as confusing as possible, so that even an expert in the field can't readily tell what is being covered in the patent.
Next, from what I can tell, the patent seems to cover 3 main points (in various flavors, to come up with their 20 points): All of these points were done years ago. The first two points were "state of the art" as of 1990. The product I worked on (name withheld for various reasons. Sorry about that...) was, at the time, unlike the other virus scanners out there. It used "precision scanning" in which the nature of the virus being scanned for was taken into account, and was scanned for ONLY AT THE LOCATION AT WHICH THE INFECTION WOULD OCCUR. This was a major differentiation from the "bulk scanners" (i.e. run the entire file through a string filter that contains all virus signatures, and see if there are any matches. As a trivia note, "bulk scanners" are why all anti-virus scanners use encrypted (in some trivial way) virus signatures -- so that a virus scanner would not be identified as an infected file by another virus scanner, or even by itself!) that all other major anti-virus vendors used.
Also, the virus scanner I wrote included a scripting language so that users could add their own virus scan and remove definitions.
As for emulating a virus target and seeing if the virus "bites", that is also old hat. While a commercial product was never introduced, a lab prototype was publically demonstrated in 1996, in which files under examination were interpreted in a virtual 80x86 environment, including OS and file system, both to see if they did anything suspicious, and to see if they "tagged along" on "provocative" system calls.
And, yes, I still have my old code sitting around. It would be a pity if someone suddenly showed it to Symantec or the patent office...