-
That is true but I don't believe that is what the previous poster was saying so here I will translate in English. In the world of programming and beta testing the programmer will send out various build. In those builds during the beta process, often times, but not always there are additional elements added to the build for use in debugging as well as logging findings in the build. They are almost always well hidden and gotten to use commands that are not at all obvious or easily gotten at. Once a build has passed beta testing, these elements, which have nothing to do with the actual operation of the build are stripped and the build is packaged in its final version for release. This is almost universal in the world of programming and extraordinarily common with Java programming since it strips out unnecessary code from releases after testing that can affect performance. Just because a beta is functionally identical to a release does not mean the leaks do not have this additional code since the leaks are beta. Like the previous poster said, the best way to check would be to compare uncompressed file size. Most of the Java debugging and reporting tools would be at least a couple of megabytes so it would be easy to tell. A very small change, say in the 10 of kb's probably would only indicate a larger or smaller vendor file.damnit people, they dont make any changes. they make a build, 155 lets say, any other coding changes done to it and it will no longer be 155, it will become a different number.
THERE IS NO ACTUAL CODING CHANGES AT ALL!!
It would be surprising if there are no debugging or reporting tools in the leak by the way, since this is a generally accepted practice for testing beta builds of all software. It actually flys in the face of reason that they would release a beta to testing without any way for the software to send reports, probably in the backround without any user input I may add. Its much more efficient than word of mouth surveys that everyone seems to think is all they use when testing the betas and it could be the reason for the hard to pin down erratic behavior of the betas.
By the way, since Blackberries run Java in a protected mode for security, debuging and reporting tools cannot be run as a program seperate from the kernel layer to get valid information, so these programs if there would need to be installed with the OS and as part of it to get the kind of root access needed. Adding the programs to the application layer would give them insufficient priveleges to get the kind of data necessary to make proper changes to code in future builds.
This is all conjecture though since debugging and reporting may happen in the alpha stage and they very well could just use dumb surveying in the beta stage but hopefully this long, long post explains enough about how programming and debugging generally works to keep people from the same ask question or make comment/receive multiple flames cycle we seem to be on here when it comes to this subject on a hundred different boards. The questioners can't know because they aren't writing or testing the software but by the same token, neither can the flamers or experts. All we can do is compare file sizes of the before and after and draw conclusions from that.
Id like to think we can close this subject now but I give the odds of that as fat chance or below.
05-30-09 02:28 AM - Let me explain the way RIM does things. They run everything on simulators until they are satisfied. Then they compile the build only to find a bug or 2 show up on the device that didn't show up on the simulator. If it is a minor bug they will send it it to carriers for testing and it is up to the carrier to accept or reject that build. Meanwhile back at the lab they are programming on the previous code to try and figure out where that bug showed up at during the compilation process. When the next build gets run through it's paces on the simulator and given theThat is true but I don't believe that is what the previous poster was saying so here I will translate in English. In the world of programming and beta testing the programmer will send out various build. In those builds during the beta process, often times, but not always there are additional elements added to the build for use in debugging as well as logging findings in the build. They are almost always well hidden and gotten to use commands that are not at all obvious or easily gotten at. Once a build has passed beta testing, these elements, which have nothing to do with the actual operation of the build are stripped and the build is packaged in its final version for release. This is almost universal in the world of programming and extraordinarily common with Java programming since it strips out unnecessary code from releases after testing that can affect performance. Just because a beta is functionally identical to a release does not mean the leaks do not have this additional code since the leaks are beta. Like the previous poster said, the best way to check would be to compare uncompressed file size. Most of the Java debugging and reporting tools would be at least a couple of megabytes so it would be easy to tell. A very small change, say in the 10 of kb's probably would only indicate a larger or smaller vendor file.
It would be surprising if there are no debugging or reporting tools in the leak by the way, since this is a generally accepted practice for testing beta builds of all software. It actually flys in the face of reason that they would release a beta to testing without any way for the software to send reports, probably in the backround without any user input I may add. Its much more efficient than word of mouth surveys that everyone seems to think is all they use when testing the betas and it could be the reason for the hard to pin down erratic behavior of the betas.
By the way, since Blackberries run Java in a protected mode for security, debuging and reporting tools cannot be run as a program seperate from the kernel layer to get valid information, so these programs if there would need to be installed with the OS and as part of it to get the kind of root access needed. Adding the programs to the application layer would give them insufficient priveleges to get the kind of data necessary to make proper changes to code in future builds.
This is all conjecture though since debugging and reporting may happen in the alpha stage and they very well could just use dumb surveying in the beta stage but hopefully this long, long post explains enough about how programming and debugging generally works to keep people from the same ask question or make comment/receive multiple flames cycle we seem to be on here when it comes to this subject on a hundred different boards. The questioners can't know because they aren't writing or testing the software but by the same token, neither can the flamers or experts. All we can do is compare file sizes of the before and after and draw conclusions from that.
Id like to think we can close this subject now but I give the odds of that as fat chance or below.
they go for compilation again. Thus moving from say 4.7.0.147 to 4.7.0.148. Every time there is a build compiled it gets a new number. So that being said .148 is .148 is .148.05-30-09 08:41 AM - So what you are saying is that when RIM releases a build to a carrier, it has gone through any programming changes testing it would. The carrier cannot alter it. If the carrier rejects or needs something changes, RIM changes and gives them a new build thus going from .141 to .148.Let me explain the way RIM does things. They run everything on simulators until they are satisfied. Then they compile the build only to find a bug or 2 show up on the device that didn't show up on the simulator. If it is a minor bug they will send it it to carriers for testing and it is up to the carrier to accept or reject that build. Meanwhile back at the lab they are programming on the previous code to try and figure out where that bug showed up at during the compilation process. When the next build gets run through it's paces on the simulator and given the they go for compilation again. Thus moving from say 4.7.0.147 to 4.7.0.148. Every time there is a build compiled it gets a new number. So that being said .148 is .148 is .148.
But if VZ accepts and releases .148, it's the same?
Why has nobody ever explained that?
05-30-09 08:54 AM - Hey your getting it.So what you are saying is that when RIM releases a build to a carrier, it has gone through any programming changes testing it would. The carrier cannot alter it. If the carrier rejects or needs something changes, RIM changes and gives them a new build thus going from .141 to .148.
But if VZ accepts and releases .148, it's the same?
Why has nobody ever explained that?
There is one file that the carrier is allowed to alter and that is the vendor.xml file that tells the device manager what OS the phone is allowed to load.05-30-09 08:59 AM
