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. 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".
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. 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 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. 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 * 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. Thanks, Chris Elford Intel Middleware Products Division -----Original Message----- From: Rana Dasgupta [mailto:[EMAIL PROTECTED] Sent: Thursday, August 10, 2006 10:51 AM To: harmony-dev@incubator.apache.org Subject: Re: [general] platform support Hi Mikhail, As far as I know, SetUnhandledExceptionFilter was introduced as a backdoor method in in Win2K SP4 to get around the problem that the SEH handlers are limited to the frame and not process wide. It does handle problems like NPE and AV, but as you point out, it works by hijacking the first and last chance debugger handlers. So, unlike VEH which are fully functional when debugging, these SetUnhandled...filters are not visible when debugging. I also believe that they execute in the context of the current thread, which means that they are not so good to handle stack corruption, SOE etc. which we are currently using VEH. Since one does not expect them to be used on the newer Windows boxes, the .Net framework overwrites them ...which means that any process that loads a Microsoft dll that has any Microsoft managed code in it ( and many do ), is at a risk that the SetUnhandled.. may or may not work. I think that SetUnhandled..was a great(probably only ) solution on the Win2K boxes, but VEH was put in place to solve some of its limitations. The bottom line is that one needs to experiment with this on several Windows boxes before we know how good or bad it is. I myself don't have a lot of experience with it. Thanks, Rana On 8/10/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > > >**Using "SetUnhandledExceptionFilter" API call we can handle hardware NPE > >for Win2k too. > >The only problem is debbuging of applications with exception filter > >installed. AFAIK debugger will catch all of these events. > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
