Elford, Chris L wrote: > Any _primary_ platform that will be supported by Harmony will probably > need to be put thru a pretty full test protocol on that platform > independent of whether it uses the same binary or a different binary.
Yes - the testing for a given platform is independent of the platform. > I > doubt that the Harmony community will want to target all possible OS > combinations initially. I think that we should have a serious > discussion on this list about the OS combinations for which we have > "volunteers on board" for "Harmony 1.0". We are having one. > > I don't believe that Harmony should achieve ubiquity by using least > common denominator interfaces. For x86 32bit-mode systems, I do think > we'll probably need to limit ourselves to one or two binaries. Hang on - do you think anyone is advocating ubiquity via LCD interfaces? What we needed was a focused discussion on the technological trade-offs, and I think we're having one. I also think that calling them "LCD" is somewhat of a charged phrase, as it pre-judges the usefulness or appropriateness. For example, using something specific to XP might not be any better but be just some kind of lock-in feature... > > See http://java.sun.com/j2se/1.5.0/system-configurations.html and > http://edocs.bea.com/jrockit/jrdocs/suppPlat/supp_50.html a list of what > combinations Sun and BEA support today with their Java5 solutions. > > I am unconvinced that a combined binary will make testing any easier. I know it was mentioned, but I don't think anyone is seriously suggesting it as a major motivation because we have to test on any platform we claim to support. The combined binary will make life easier for users and distributors. This started as a debate over whether or not we will even support win2k, because people were trying to use harmony on it. >I > believe that the makefile (oops, I mean ant) structure will be easier > with a combined binary but the startup code and some platform specific > optimization code will be more complex as it will need a pretty > sophisticated platform determination and a somewhat manual library > loading process. At the same time, I believe a combined binary that > includes multipath checks will simplify distribution. I also believe > that something similar will be necessary for Linuxes though perhaps not > as sophisticated. Right. Exactly. > > Lets say that we decide to go for "complete", "optimal", windows > support. We would have special case code that chooses appropriate > library interfaces at startup for somewhere between 7 and 18 different > versions of x86 windows, not accounting for service packs: > * x86 Vista home, pro, tablet > * x86 Vista/Longhorn server, webserver > * x86 Vista/longhorn enterprise Do you think this software will ever be released? :) It would be interesting to see if what we have runs on Vista now. Anyone have a copy running? > * x86 XP home, pro, tablet, media > * x86 XP/2003 server, webserver, Enterprise, Datacenter > * x86 W2K > * x86 W2K Server, W2K Advanced Server, Datacenter > > This of course doesn't account for the either EM64T or Itanium family > processor based systems. Maybe someone needs to take each OS platform > and list what special interfaces are useful for each one. I'm > particularly partial to some of the interfaces available only on the > server versions such as the large page APIs: > http://windowssdk.msdn.microsoft.com/en-us/library/ms694004.aspx. > > http://windowssdk.msdn.microsoft.com/en-us/library/ms724833.aspx talks > about how to distinguish the different versions and service packs from > each other. This is probably pretty useful information to report back > to JIRA in the case of a VM crash if we have a single binary release > model. Of course if one wants to be able to run on windowsMe or > Windows98, one can't rely on these interfaces... But then since these > aren't actively supported by Microsoft anymore, its unclear how relevant > those platforms are. I think fairly irrelevant, but if someone did step up and wanted to do the work, I wouldn't stand in their way :) geir --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
