On Wednesday December 5 2007 13:35, James McKenzie wrote: > L. Rahyen wrote: > > On Sunday December 2 2007 03:43, James McKenzie wrote: > >> L. Rahyen wrote: > >>> On Saturday December 1 2007 20:57, Dan Sawyer wrote: > >>>> All, what is the status of dcom98? Is it still expected to run native? > >>> > >>> It is expected that users will use builtin libraries. If it doesn't > >>> work you should file a bug report at http://bugs.winehq.org . > >> > >> L. Rahyen: > >> > >> This is a known issue and have open bugs on the Bugzilla for many > >> programs. I am looking at 10134, filed by Dan Kegel and is in the Wine > >> 1.0 list as an example where .NET will not run reglib.exe > >> appropriately, and their is a fix that was incorporated in 0.9.50. > >> However, I have not tested this, yet as I am waiting on a build for the > >> Mac. > > > > I know a lot of known issues. But this doesn't matter. Users are > > *expected* to use builtin libraries. If this doesn't work they should go > > to the bugzilla and report a bug (of course they are expected to search > > for already reported bugs first so to not report known problem twice). > > They can provide some additional information such as "use of native > > dcom98 is an possible workaround" - this is useful to narrow down > > possible causes of a bug. > > After a lengthy off-list conversation, I would like to state that we > need to triage issues and correct the > component to be appropriate. I would also like to add that we need to > add the keyword DCOM98 for > all issues where the solution is to use the native version of DCOM98. > This will allow the developers, > triage and quality assurance (those who test ths solutions) to quickly > determine which issuses need to > be examined whenever a solution is found. I suggest you to post this to wine-devel. Most developers (and most likely bugzilla admins) don't read wine-users so it is important to post this to wine-devel if you really want additional keyword to be added to the bugzilla (or propose any other change). > This can be extended to use of > other native dlls and program > packages. This will also allow others to quickly find workarounds until > a permanent solution is found. There is already a lot of tools for such workarounds. And users who want to find them can do this easily by googling for specific issues. But such tools never will be a part of WINE because they hide problems and indirectly harm the project. Most bugs are still unknown and DCOM isn't an exception. As long as this is the case you cannot harmlessly use native library by default in WINE and only when builtin is 100% compatible with native you can safely use native - but in this case you don't need it. By the way, use of native library instead builtin one isn't always good thing for simple-user-who-never-will-report-a-bug either. Native libraries aren't always 100% WINE-compatible and their use may lead to strange crashes. And of course native libraries sometimes may contains bugs too. In other words, use of native libraries instead of builtin ones will be an option for users and developers who *really* need this but this never will be the default (and WINE will never include in main tree tools for automatic overrides). _______________________________________________ wine-users mailing list wine-users@xxxxxxxxxx http://www.winehq.org/mailman/listinfo/wine-users
