A long time ago I developed a program that was protected by a HASP, i.e., a small device connected to the parallel port, and allowes to protect the software.
For development, I didn't want to buy a lot of HASPs and so, so I removed the testing. However, as far as I can tell, I never gave anyone an executable w/o the protection.
Suppose you want a PC connected to, say, 10 disk drives, in order to implement RAID 5+1 in software. What you do is: take a SCSI controller, and connect to 10 IDE drives, using this device. This is the most cost-effective way! There is no other way I know to connect a large array of IDE drives to a PC. Using SCSI will cost much more.
Recently, I developed a tool for Forward Error Correction codes (FEC). When encoding and decoding packets, I use memory-mapped files, since I need random access and virtual memory optimizations, as done by modern OSs.
Working with up-to 1GB was simple. I memory-mapped the entire file, and access it. In order to break the 2GB barrier (the user-space virtual address space size), I had to implement a sort of "cache" that remembers the last areas I accessed, and map only those areas into memory. I had to map and un-map areas when switching from one area of the file to another. Instead of a clean and efficient code I now have ugly, complex, and bug-prone code.
I think having 64-bit virtual address space is critical for today's applications.
Just a note: The Windows virtual memory manager is horrible. Developed for Linux 2.4, our product worked great. Random file access decoding, of 1GB file, on 100MHz Pentium-I based set-top-box with 64MB RAM, and slow hard-drive -- at ~10mbps. When ported to Windows 2000/XP, a 700MHz Pentium-3 with 256MB RAM and modern hard-drive could not even get close to the set-top-box. I am talking about a factor of x20 in performance!
The Windows version didn't commit pages to disk -- it simply ate more and more memory, until the computer became unworkable. Alternatively, when removing the memory-mapped from a part of the file, Windows did a sync() on that part, caused a delay, and an x10 performance penalty. A lot of optimizations were needed to overcome these problems. Still, the Linux version is x3 faster. (I didn't test kernel 2.5 yet).
First, the cell phones can always use some form of tunnels and network address translators. For example, when you want to talk with a phone, you will open an HTTP connection to http://host.com/+1-222-333-4444, and use HTTP messaes in order to transmit information from side to side, as if it is a TCP connection (this can be done). Only the server has IP address. From there, it is native protocols of the cell phone.
Second, if the cell phones become IPv6, and Microsoft users will not be able to talk with them, I am sure that Microsoft will implement it in a second. Do not underestimate the power of the phone industry. There are still more phones than computers.
Like in a lot of cases, you can use strong cryptography to solve this.
Id should create two version of Quake: An open-source version, and a binary version. The versions will be almost identical, except one thing: the binary version will use strong cryptography to pass it's messages. When connecting to open-source version of Quake server, or a Quake client, a player with the binary version will get a warning. Then, he/she can decide to play or not.
It is possible to use private-key cryptography (no need for public-key cryptography). However, the binary version will need some kind of anti-debugging code.
Slashdot Mirror
For development, I didn't want to buy a lot of HASPs and so, so I removed the testing. However, as far as I can tell, I never gave anyone an executable w/o the protection.
Would you consider it a backdoor?
Come and see the Comun Yerge
Suppose you want a PC connected to, say, 10 disk drives, in order to implement RAID 5+1 in software. What you do is: take a SCSI controller, and connect to 10 IDE drives, using this device. This is the most cost-effective way! There is no other way I know to connect a large array of IDE drives to a PC. Using SCSI will cost much more.
Working with up-to 1GB was simple. I memory-mapped the entire file, and access it. In order to break the 2GB barrier (the user-space virtual address space size), I had to implement a sort of "cache" that remembers the last areas I accessed, and map only those areas into memory. I had to map and un-map areas when switching from one area of the file to another. Instead of a clean and efficient code I now have ugly, complex, and bug-prone code.
I think having 64-bit virtual address space is critical for today's applications.
Just a note: The Windows virtual memory manager is horrible. Developed for Linux 2.4, our product worked great. Random file access decoding, of 1GB file, on 100MHz Pentium-I based set-top-box with 64MB RAM, and slow hard-drive -- at ~10mbps. When ported to Windows 2000/XP, a 700MHz Pentium-3 with 256MB RAM and modern hard-drive could not even get close to the set-top-box. I am talking about a factor of x20 in performance!
The Windows version didn't commit pages to disk -- it simply ate more and more memory, until the computer became unworkable. Alternatively, when removing the memory-mapped from a part of the file, Windows did a sync() on that part, caused a delay, and an x10 performance penalty. A lot of optimizations were needed to overcome these problems. Still, the Linux version is x3 faster. (I didn't test kernel 2.5 yet).
I don't think that Yahoo! should charge me at all.
Second, if the cell phones become IPv6, and Microsoft users will not be able to talk with them, I am sure that Microsoft will implement it in a second. Do not underestimate the power of the phone industry. There are still more phones than computers.
Doron.
Isn't there anything better to do with all this CPU?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well done! Do it! Doron. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBOUKoVR2gnDEW5AIHEQKRBACfVWgqf5jz9QuEWBuRX2 HUfjH1zKoAoLWV 5YcMdBr5BPGE8dqV6tGgc737 =N3GN -----END PGP SIGNATURE-----
Id should create two version of Quake: An open-source version, and a binary version. The versions will be almost identical, except one thing: the binary version will use strong cryptography to pass it's messages. When connecting to open-source version of Quake server, or a Quake client, a player with the binary version will get a warning. Then, he/she can decide to play or not.
It is possible to use private-key cryptography (no need for public-key cryptography). However, the binary version will need some kind of anti-debugging code.
Doron.