wine-devel June 2005

wine-devel@winehq.org

163 participants
316 discussions

Re: dlls/gdi/dib.c GetDIBits
by Uwe Bonnes 01 Jun '05

01 Jun '05

>>>>> "Ulrich" == Ulrich Czekalla <ulrich.czekalla(a)utoronto.ca> writes: Ulrich> This patch fixes a regression that happened quite sometime Ulrich> ago. We don't always fill in the BITMAPINFO struct fields on the Ulrich> way out and this broke my app because it uses these values to Ulrich> allocate enough memory to hold the bits. Ullrich, I see a lot of indentation change and only 2 or 3 lines of real code change. Can you perhaps resent with the real code change better visible? I have a problem with CopyImage, maybe it is affected by the regression you fix. Tagging the changes for debugging can help me to be sure about the change. Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 2

Age of Empires 2 splash screen
by Ivan Leo Puoti 01 Jun '05

01 Jun '05

I actually got this for the first time a few days ago, but I thought I might as well share it as I think it's cool. AFAIK DMCA compliant code has never got this far with safedisc 1. http://www003.portalis.it/115/download/aoe.png Ivan.

1 0

Re: Borland C++ 4.5
by gslink 01 Jun '05

01 Jun '05

This started happening on FC3 with the 2.6.11 kernels in programs running under the Sun 1.42 jre. I was using the Nvidia driver supplied with the kernel. I changed to the driver posted on the Nvidia web site and have had no further trouble. I tried to duplicate the problem but it happened so infrequently that I could never quite find it. I am not sure that this problem is with Wine.

2 1

Print unicode strings in tests
by Paul Vriens 01 Jun '05

01 Jun '05

Hi, I'd like to print unicode-strings in some tests (for debugging purposes). The following however does not show nice output on wine (it does on windows): static const WCHAR dataW[] = {'S','o','m','e',' ','d','a','t','a',0}; UNICODE_STRING usdata = { sizeof(dataW)-sizeof(WCHAR), sizeof(dataW), (LPWSTR)dataW }; trace("Length is %d\n", usdata.Length); trace("Maximum Length is %d\n", usdata.MaximumLength); trace("The strings is %ls\n", usdata.Buffer); Our trace doesn't seem to be able to cope with %ls (or %S). Any ideas ? Cheers, Paul.

3 2

Re: Optionally map the unix filesystem instead of drive letters into the shell namespace
by Michael Jung 01 Jun '05

01 Jun '05

Hi Michael, On Friday 27 May 2005 03:03, Michael Lin wrote: > Just a few things with this approach. > As I mentioned before .. with a global flag in the registry. > User can't run a winelib application with unix path and a Windows > application on Wine with dos path at the same time. Please consider the configure based global flag only an option. That's actually what I said several times. It could be a per application option as well. And there is no problem in activating it via a wine-specific API, which would override the config on a per process basis. > Ok ... I know your approach is base everything on dos path and the > global flag is simply a display mode. > But what about the parsing of the file name editbox in the file dialog? > The user is browsing unix file system, but does the user enter unix or > dos path? > I believe I can modify your solution to accept unix file path, but it > have to accept dos path as well. Modifying shfldr_unixfs to parse unix path in addition to dos paths is trivial: Just remove the (pUnixFolder->m_dwPathMode == PATHMODE_UNIX) test in line 339. The real problem is the test for invalid chars in the filedialog, which '/' is one of. The solution is obvious: If wine is configured to display unix paths, then accept '/' as a valid char in paths in comdlg32. You will have to do this for your solution as well, don't you? > Then there is also the issue of having to have the unix root mapped to a > dos drive. That's true. Actually, we are tackling two slightly different problems here: I would like to have existend applications, for which I don't have the source, to display unix paths instead of dos paths in their file dialogs. So I want MS Office to display unix paths in it's file dialogs. IMHO there is not way to achieve this without the requirement to map one of the dos drives to '/'. At least not if the user should be able to access every file on his filesystem. This solution can also be applied to winelib applications. If you want to use the native posix file functions (which, frankly, I don't see a reason to do, because the user doesn't care how filenames look in the core dump, but only how they look on the screen) then just map the paths coming out of the file dialog to unix with the wine_nt_to_unix_path function. I do understand that there are some shortcomings of this approach for winelib applications, which can not possibly be addressed this way. But it seems equaly obvious to me that your approach can never achieve the goal I laid out above (To make native apps display the unix paths in file dialogs). So perhaps there might be demand for both solutions. Or perhaps I'm totaly off the point and the only person on the planet who likes to see unix paths in his native windows applications on wine. Which would mean your solution might be the only one people are interested in. What I meant to say is, please fell free to implement your solution the way you like it and let the wine community decide on it. But please don't modify shfldr_unixfs in a way that breaks my solution (Conceptually, that is. Bugs, of course, are unavoidable.) > Troy, Alexandre and I have been discussing other possible solutions to > this problem offline. I don't want to offend, but I think this just isn't fair. I have contributed a lot of my free time working on this stuff, and I think I would have deserved to be informed on discussions and decisions in this matter. Above that, this kind of discussion should take place on wine-devel, so that the community at large can take part in it. To me this gives the impression that you avoided discussing it on wine-devel, because you didn't want to be convinced. Sorry. Ok, nuff said, going back to the technological stuff. > One solution I have implemented and waiting on Alexandre's verdict is > the following. > > Create a new library called wineunixfs. All additional entry point > should be in that library. > All exported function call should be of the same signiture as one in the > core library such as GetOpenFileNameA(), GetOpenFileNameW() etc. > To use the library, simply let winelib application link it before all > the other core libraries. > > My Changes to the core libraries are contained within shell32. There is > only one extra exported functions SHUnixFSGetDesktopFolder() being > added. This function return the desktop folder in unix mode. > > Currenlt wineunixfs duplicates filedlg.c, filedlgbrowser.* and their > dependent files from commdlg. > I have attached the diff file for the rest of the changes that's on the > core libraries. I'm not the one to judge, but in my opinion this is pretty heavy weight. Ciao, -- Michael Jung mjung(a)iss.tu-darmstadt.de

2 3

Re: Fix NtAccessCheck so it works with relative SECURITY_DESCRIPTORs
by Robert Shearman 01 Jun '05

01 Jun '05

Evan Deaubl wrote: >ChangeLog: > * Fix NtAccessCheck so it works with relative SECURITY_DESCRIPTORs > > I cleaned up the patch a little. Does this still work for you? Changelog: Evan Deaubl <wine(a)warpedview.com> Robert Shearman <rob(a)codeweavers.com> - Implement RtlGetControlSecurityDescriptor - Fix NtAccessCheck so it works with relative SECURITY_DESCRIPTORs -- Rob Shearman

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel June 2005