Rana Dasgupta wrote: > Geir, > Certainly we can support w2k if we choose to. But I think that the right > way to do this is to implement, build and test for W2K, not by disabling > code that will not run on it by trying to support a single binary image > across OS's. The DRLVM code has not been tested on w2k.
I don't grok why you've said this twice now - why don't we just test it? I don't mind telling people what it's been tested on, and also tell them that for other platforms, they are on their own. > It may not be a > good > idea to try to achieve this by commenting out the code piece by piece as we > hit bugs. That's not a fair description of what happened. First it wasn't a bug, and it was a conscious decision to eliminate a dependency and usage of it's API in order to help a user try a snapshot on Win2K. > Are we choosing build on and support W2K as a platform of choice > for Harmony? If we don't want to do this and just want to somehow enable > one > user, we should at least consider branching this code. We could also consider why we use these special winXP features, and if we'd achieve the same functionality with another technical approach, while broadening our possible user base. Remember, one of our goals here is broad adoption across platforms... > I did not understand your comment about compile time/run time. > _WIN32_WINNT is the standard way to distinguish between Windows platforms > and is used everywhere to check platform capability. At compile time, right? If we want a binary that is for both win2k and winXP, and there is some requirement to use a winXP API, you can't use a #define to do this - you need to check at runtime. > Are you proposing that > we should make dynamic runtime os version checks? I am not sure what is the > benefit of that. The point is to avoid having to ship a separate binary for every flavor and service pack of windows that we choose to support. If we can engineer one binary that runs on all, we're better off. It might be better if we stepped back and looked at why using the winXP API is necessary, and explore alternatives. > Regarding your question about whether if it runs on w2k it will also run > on xp, I am not sure. Usually windows oS's are binary backward compatible > till ~ W2K, meaning that a W2K binary should somehow run on forward OS's. > But that is designed only for legacy support and cannot be used for > performance etc. The last statement is interesting - what is the performance cost in not using the winXP API but rather using something else that is backwards compat to Win2k? geir > > > > > > On 8/8/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >> >> >> >> Rana Dasgupta wrote: >> > Hi, >> > We have commented out all the stack trace handling code etc. in the NT >> > exception handing code in drlvm to get the same binary image to run on >> an >> > old OS like W2K. I am sorry, but I disagree with this approach. >> >> Why? We wanted to make it so a user could try it out. We discussed the >> approach, and it was a quick fix. What's the problem? >> >> > We cannot >> > compile sources meant for XP/W2003 and expect the binaries to run on >> lower >> > Windows OS's. Now we are hitting problems with the vectored exception >> > handlers which also don't exist on W2K. We cannot comment these out >> also! >> >> No, but we can re-engineer what we're doing. >> >> >> > As Alexey has pointed out, we need to guard the code with the right >> > _WIN32_WINT guards. The define is 0x501 on XP and 0x502 on W2003. >> Unless >> > someone has objects, I am going to turn all this code back on with the >> > right >> > _WINT filters. >> >> Defines don't solve the problem because they are compile-time, not >> runtime. >> >> > VEH is a feature in the new Windows code base ( the kernel, >> > debug etc. are common to both OS's and quite different from W2K ). >> If we >> > want to support W2K, we will need to rewrite the relevant excpetion >> > handling >> > portions and do a build for W2K seperately. >> >> Why? Would the solution for W2k not run on WinXP? >> >> >> > The DRLVM code has not been >> > tested on W2K. There could be more problems. Worse, the code will >> resolve >> > the symbols, but behave differently. >> >> Right, and the point of making things work for the W2k user is to let >> that person help test. >> >> > A part of the problem is that we haven't defined the minimum machine >> model >> > where we want our code to be supported. I would propose that for >> > x86-W32, we >> > define it as Intel Pentium IV and WinXP and Windows Server 2003. >> >> And why not 2k? >> >> > This would >> > allow us to get away from all these lower level kernel support and also >> > allow us to avoid doing a lot of unnecessary JIT floating point >> work. If >> we >> > want to support W2K and older machines Pentium III, we will need to >> make >> > all >> > the code changes needed for it and also test it on the down level >> machines. >> > >> > Thanks, >> > Rana >> > >> > >> > >> > On 8/7/06, Ivanov, Alexey A <[EMAIL PROTECTED]> wrote: >> >> >> >> >> >> >-----Original Message----- >> >> >From: Paulex Yang [mailto:[EMAIL PROTECTED] >> >> >Sent: Monday, August 07, 2006 7:57 AM >> >> >To: harmony-dev@incubator.apache.org >> >> >Subject: Re: [general] new snapshots up early morning... is the win2k >> >> >problem gone? >> >> > >> >> >Sorry for response so late, I must get to office for a win2k PC... >> >> > >> >> >Just tried it, the dgbhelp.dll error gone, but another one emerge: >> >> > >> >> >"Cannot locate entry AddVectoredExceptionHandler at kernel32.dll" >> >> >(translate from Chinese so probably you'll get a slightly different >> >> >message from this) >> >> >> >> AFAIK this feature (vectored exceptions) is available in Windows XP >> >> only. >> >> So it seems we need separate build for Win2K. >> >> >> >> Regards, >> >> Alexey. >> >> >> >> > >> >> >Env: >> >> >win2k+sp4 >> >> >.net framework 1.1 >> >> >Windows PlatformSDK for Win2003 >> >> > >> >> >Geir Magnusson Jr wrote: >> >> >> can anyone test? >> >> >> >> >> >> geir >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> >> >> To unsubscribe, e-mail: >> [EMAIL PROTECTED] >> >> >> For additional commands, e-mail: >> >> [EMAIL PROTECTED] >> >> >> >> >> >> >> >> >> >> >> > >> >> > >> >> >-- >> >> >Paulex Yang >> >> >China Software Development Lab >> >> >IBM >> >> > >> >> > >> >> > >> >> >--------------------------------------------------------------------- >> >> >Terms of use : http://incubator.apache.org/harmony/mailing.html >> >> >To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> >For additional commands, e-mail: >> [EMAIL PROTECTED] >> >> >> >> -- >> >> Alexey A. Ivanov >> >> Intel Middleware Product Division >> >> >> >> --------------------------------------------------------------------- >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> >> --------------------------------------------------------------------- >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
