August 2007 - Wine-Devel - list.winehq.org

Re: .NET support

by Jakob Eriksson

Bryan DeGrendel wrote: > On 8/29/07, Jakob Eriksson <jakob(a)vmlinux.org> wrote: > >> Now that GDIplus is shaping up, is there a chance of implementing .forms >> support in mono with it? >> >> regards, >> Jakob >> >> >> >> > > I haven't observed any Mono on Wine problems with GDI+. Do you have a > .NET application that runs on Native Windows Mono but not Wine Windows > Mono? > > Bryan DeGrende No, I wasn't clear enough. Roderick helped me (by having his act together.) regards, Jakob

Aug. 30, 2007

Re: .NET support

by Roderick Colenbrander

On Thursday 30 August 2007 17:49, Jakob Eriksson wrote: > Roderick Colenbrander wrote: > > On Thursday 30 August 2007 00:35, Jakob Eriksson wrote: > >> Now that GDIplus is shaping up, is there a chance of implementing .forms > >> support in mono with it? > >> > >> regards, > >> Jakob > > > > Mono contains its own version of gdiplus for rendering system.drawing and > > in the end Windows.Forms. Though on windows I think it uses the native > > gdiplus.dll. You can install the win32 version of mono and see if it > > works. > > > > I'm not sure what you had in mind. > > Well, Monos version of Windows.Forms isn't exactly 100% compatible with > .NETs. > > I figured now that the foundation of a REAL (gdiplus) is coming > together, it might built on that instead. > > regards, > Jakob I think the incompatibilities you mean are for instance that in case of Mono you can mix Windows.Forms with win32 calls. If you don't like the behavior of something you can call a standard gdi32/user32 function and change some stuff. Things like that work because I think the .NET version of Windows.Forms maps to win32 controls. Mono renders everything itself through System.Drawing. I don't think a different gdiplus.dll will make any difference for this. To allow mixing of Windows.Forms with gdi32 stuff everything needs to be rendered using native controls. That's what mono attempted years ago using Wine but they had various Wine integration troubles and we didn't come to a good solution for it. Roderick

Aug. 30, 2007

Re: .NET support

by Bryan DeGrendel

On 8/29/07, Jakob Eriksson <jakob(a)vmlinux.org> wrote: > > Now that GDIplus is shaping up, is there a chance of implementing .forms > support in mono with it? > > regards, > Jakob > > > I haven't observed any Mono on Wine problems with GDI+. Do you have a .NET application that runs on Native Windows Mono but not Wine Windows Mono? Bryan DeGrendel

Aug. 30, 2007

Re: try2:patch for sysparams.c

by L. Rahyen

On Thursday August 30 2007 14:21, Robert Shearman wrote: > L. Rahyen wrote: > > On Thursday August 30 2007 07:03, you wrote: > >> Hello, > >> > >> I have corrected a patch. Now font in the menu and a font in winecfg > >> coincides. > > > > Please note that your patch behaves even worse at higher DPI > > resolutions. For example if I set: > > > > "LogPixels"=dword:00000096 > > > > ...In system.reg then menu font is of ridiculosly big size. > > I'm not surprised. 0x96 = 150 Yes, and in both Windows and current WINE (without the patch) this looks very good (as it should) on my 22" display! Just compare attached screenshots (please note that I have scaled down them by 50% in order to save the bandwidth). "broken.jpg" shows problem I'm talking about. This is with clean WINE with clean WINEPREFIX *with* applied last version of patch that was sent to me privately. As you can see, notepad's dialog and its menu is of ridiculously big size! Behind notepad and winecfg you can see Windows with default font size but with DPI set to 150 (WINE DPI setting is same). Menu in notepad and its dialog is of normal size in Windows, everything looks very nice. Note that all fonts in Windows are of same size no matter what DPI I set there. "clean.jpg" is made using clean WINE with clean WINEPREFIX with LogPixels set to 150 DPI. Behind you can see Windows (in VMWare). Please note that because of clean WINEPREFIX fonts are somewhat different but their system-default size and DPI setting in WINE and Windows are the same here. As you can see, with clean WINE without the patch everything looks as it should. Even the dialog box in both WINE and Windows is of almost same size ("almost" because of somewhat different fonts and different titlebars). This proofs correct behavior of current clean WINE and shows that it respects LogPixels value correctly. My impression is that the patch Ivan Sinitsin proposing is a hack to make font size in menu/dialog/status bar bigger in every application because 1C application displays smaller fonts there than others. But in its current state this hack is very destructive (as you can see in above example). And of course if on Windows 1C applications behaves in the same way WINE should behave like this too. In fact I have seen (and even use some of them on regular basis) Windows applications which set small font size in some GUI elements even with big DPI setting so I will not be surprised if 1C application in question is just another one.

Aug. 30, 2007

Re: .NET support

by Jakob Eriksson

Roderick Colenbrander wrote: > On Thursday 30 August 2007 00:35, Jakob Eriksson wrote: > >> Now that GDIplus is shaping up, is there a chance of implementing .forms >> support in mono with it? >> >> regards, >> Jakob >> > > Mono contains its own version of gdiplus for rendering system.drawing and in > the end Windows.Forms. Though on windows I think it uses the native > gdiplus.dll. You can install the win32 version of mono and see if it works. > > I'm not sure what you had in mind. > Well, Monos version of Windows.Forms isn't exactly 100% compatible with .NETs. I figured now that the foundation of a REAL (gdiplus) is coming together, it might built on that instead. regards, Jakob

Aug. 30, 2007

Re: .NET support

by Roderick Colenbrander

On Thursday 30 August 2007 00:35, Jakob Eriksson wrote: > Now that GDIplus is shaping up, is there a chance of implementing .forms > support in mono with it? > > regards, > Jakob Mono contains its own version of gdiplus for rendering system.drawing and in the end Windows.Forms. Though on windows I think it uses the native gdiplus.dll. You can install the win32 version of mono and see if it works. I'm not sure what you had in mind. Roderick

Aug. 30, 2007

Re: AppDB entries

by Alexander Nicolaysen Sørnes

Torsdag 30 august 2007 13:19, skrev speedator(a)gmx.de: > Hi, > sometimes app-entries (like Acrobat Reader) are for series of > applications and versions for the single applications. Sometimes there > are app-entries(like Age of Empires) for single applications in a series > and version-entries for patches, betas, demos etc.. And > sometimes it is a mixture. > > What about making this more clear? Do we need entries for the whole > series? I think it is important for overview. So what about a new > structure like "application / version / derived from version(subversion)"? > > Julian There is a difference between games and other applications. Adobe Reader 5 and 7 are versions of the same program, but say Command & Conquer Tiberian Sun and Command & Conquer Red Alert are not versions of the same game; they are very different. Alexander N. Sørnes

Aug. 30, 2007

Re: try2:patch for sysparams.c

by Robert Shearman

L. Rahyen wrote: > On Thursday August 30 2007 07:03, you wrote: > >> Hello, >> >> I have corrected a patch. Now font in the menu and a font in winecfg >> coincides. >> > > Please note that your patch behaves even worse at higher DPI resolutions. For > example if I set: > > "LogPixels"=dword:00000096 > > ...In system.reg then menu font is of ridiculosly big size. I'm not surprised. 0x96 = 150 -- Rob Shearman

Aug. 30, 2007

Re: dsound: Disable thread calls and increase refcount in dllmain

by Alexandre Julliard

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > I want to be able to rename the dll without having to worry about that > line. That's why I'm getting the full file name. Easier to run tests > that way. You should use GetModuleHandleEx to increment the refcount directly from the module handle. -- Alexandre Julliard julliard(a)winehq.org

Aug. 30, 2007

Re: dsound: Disable thread calls and increase refcount in dllmain

by Maarten Lankhorst

Dmitry Timoshkov schreef: > "Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> wrote: > >> Seems native directsound keeps itself loaded by calling LoadLibrary when >> attaching. A simple testcase I wrote confirms that at least for xp, by >> not crashing. > > After seeing this, I decided to write my own test, and can confirm now > that this > patch looks correct: after a successful LoadLibrary("dsound.dll") > FreeLibrary > needs to be called 2 times before it starts to return FALSE. > > Just for fun I tested other dlls as well (GetModuleHandle returns 0 > for all of them > before the LoadLibrary call): > user32 requires 4 FreeLibrary calls after LoadLibrary, dinput - 1, > mfc42 - 1, > advapi32 - 1, comctl32 - 1. > > I'm attaching the program I used for testing. > >> + GetModuleFileNameW(hInstDLL, modname, >> sizeof(modname)/sizeof(*modname)); >> + LoadLibraryW(modname); > > Probably simple LoadLibrary("dsound.dll") should be enough. I want to be able to rename the dll without having to worry about that line. That's why I'm getting the full file name. Easier to run tests that way. It gets even more fun in another part: If you load a dll at link time, then also load it with loadlibrary, you can call freelibrary as many times on it as you like, it won't unload. However in wine it will... potentially causing crashes for badly written programs.

Aug. 30, 2007