January 2004 - Wine-Devel - list.winehq.org

Re: DPA_Create/Search may be missing

by Francois Gouget

On Fri, 16 Jan 2004, Hans Leidekker wrote: [...] > Did you by any chance build the test with MinGW? No, I compiled it with Microsoft Visual C++ 6.0. I made sure to get the latest and complete Windows SDK too as the previous one I had was missing 'shlwapi.h'. > I submitted a > patch like yours a while ago and it was rejected because DPA_Create > & friends where present in comctl32 but are exported by ordinal only. Hmmm. Yes, it's possible that the test should load the DPA function by ordinal. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ La terre est une b\xEAta...

Jan. 16, 2004

Re: Shell32 patch from ROS 2

by Marcelo Duarte

OK. Relatively to files shlexec.c (ShellExecute, etc) I will do it. Others with you ;) ----- Original Message ----- From: "Steven Edwards" <steven_ed4153(a)yahoo.com> To: <wine-devel(a)bol.com.br>; <wine-patches(a)winehq.org> Sent: Friday, January 16, 2004 2:15 PM Subject: Re: Shell32 patch from ROS 2 > Hello Marcelo, > --- Marcelo Duarte <wine-devel(a)bol.com.br> wrote: > > Changelog: > > "Martin Fuchs" <martin-fuchs(a)gmx.net> > > - fixed HCR_GetExecuteCommandExA/W() to correct ShellExecuteEx() > > behaviour > > with flag SEE_MASK_CLASSNAME set > > Thanks for your help merging this patch. > Steven > > > __________________________________ > Do you Yahoo!? > Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes > http://hotjobs.sweepstakes.yahoo.com/signingbonus

Jan. 16, 2004

Re: Html Help

by Dimitrie O. Paun

On January 16, 2004 10:11 am, Martin Fuchs wrote: > Why not just configure everything in the registry and use ShellExecute() to > launch the correct applications this way? Even better. To be honest, I haven't looked into why we need this apps, it's just that I'm a little concerned we're gonna end up with too many :) -- Dimi.

Jan. 16, 2004

dmesg error about pthreads

by Kevin DeKorte

On my FC1 system with the latest patches I'm getting this in the dmesg log. Been getting them for awhile. application bug: wine-pthread(4537) has SIGCHLD set to SIG_IGN but calls wait(). (see the NOTES section of 'man 2 wait'). Workaround activated. wine -v Wine 20031212 Is this anything I need to worry about Kevin

Jan. 16, 2004

Re: Html Help

by Martin Fuchs

> On January 10, 2004 12:42 am, Acke Carlsson wrote: > > Heavy based on Chris Morgan's winebrowser i cut/paste a winehh, to use a > > Unix chm-file viewer. It works when there is no space in the path. How > to > > do the transform from windows path to Unix path right? > > This is getting a bit out of hand. We can't have a wineXXX for every > XXX-type application, it's too much. What we need is a winelauncher > app, that knows how to start different types of apps. Like so: > > winelauncher browser ...other args... > > There are other generic app types that may qualify: text editors, > file managers, whathaveyou. Why not just configure everything in the registry and use ShellExecute() to launch the correct applications this way? -- Martin Fuchs martin-fuchs(a)gmx.net +++ GMX - die erste Adresse für Mail, Message, More +++ Bis 31.1.: TopMail + Digicam für nur 29 EUR http://www.gmx.net/topmail

Jan. 16, 2004

Re: Html Help

by Dimitrie O. Paun

On January 10, 2004 12:42 am, Acke Carlsson wrote: > Heavy based on Chris Morgan's winebrowser i cut/paste a winehh, to use a > Unix chm-file viewer. It works when there is no space in the path. How to > do the transform from windows path to Unix path right? This is getting a bit out of hand. We can't have a wineXXX for every XXX-type application, it's too much. What we need is a winelauncher app, that knows how to start different types of apps. Like so: winelauncher browser ...other args... There are other generic app types that may qualify: text editors, file managers, whathaveyou. -- Dimi.

Jan. 16, 2004

Re: Try using the Mozilla Active X control in MSHTML

by Dimitrie O. Paun

On January 16, 2004 01:37 am, Vincent Béron wrote: > The ActiveX control listed at the listed address is self-contained (but > still 5MB in size), so it's probably not much work to package it as > well. Perfect! I'm fairly excited about this stuff. BTW Mike, did you try to see if HTML Helps works with the Mozilla control? We had a task to add CHM support to WinHelp, but first we needed an implementation for IWebBrowser. People were arguing that Mozilla is not that IE compatible, and that using it for the IWebBrowser component will not work for a lot of cases, but I still think this is the way forward. Even if we chose in the future to have another IWebBrowser implementation based on khtml, this will nicely fill in the gap in the meanwhile, without any maintenance problems for us. -- Dimi.

Jan. 16, 2004

Re: Add iccvid.spec to winapi_check

by Dimitrie O. Paun

On January 16, 2004 03:48 am, Hans Leidekker wrote: > Then it would simply be a matter of doing: > > find dlls/ -name "*.spec" > > or some equivalent of that, and we can get rid of synchronizing > winapi_check by hand. We can do that even now, by turning the problem inside out: -- teach winapi_check the simple find trick -- provide a (manually maintained) list of exceptions -- Dimi.

Jan. 16, 2004

Re: DPA_Create/Search may be missing

by Hans Leidekker

On Friday 16 January 2004 11:57, Francois Gouget wrote: > On NT4 (or is that on Internet Explorer <=5?), comctl32 is missing entry > points for DPA_Create and DPA_Search. So we need to link them > dynamically if we want the rest of the tests to run. Did you by any chance build the test with MinGW? I submitted a patch like yours a while ago and it was rejected because DPA_Create & friends where present in comctl32 but are exported by ordinal only. MinGW's libs export these by name, not ordinal only, so the resulting binary will not run on Windows. -Hans

Jan. 16, 2004

Re: Implement LockWindowUpdate [take 3]

by Mike Hearn

On Fri, 2004-01-16 at 05:43, Alexandre Julliard wrote: > Yes it's much better. Now the problem is that the rest of the code > won't be able to cope with it: in order to make sure painting always > happens correctly, you will need to invalidate all the DCEs concerned > by the window, to make sure all the update regions are recomputed > correctly. Unfortunately this can't be done inter-process at the > moment... That went over my head I'm afraid. What do you mean by concerned? Could you have told me this when I first submitted my patch? I feel it's been a bit of a waste of time now - looking at the code it seems that inter-process invalidation is not trivial thing. Perhaps the code could be committed but disabled (just stick a return in the first line of LockWindowUpdate) with a comment in RedrawWindow to the effect of /* When inter-process invalidation is complete remember to re-enable LockWindowUpdate */ otherwise I expect by the time we get this feature everybody will have forgotten about the patch. thanks -mike

Jan. 16, 2004

Re: slight trouble running winetests under windows

by Hans Leidekker

On Wednesday 14 January 2004 22:52, Alexandre Julliard wrote: > > Looks like a solution to me. What about dxguid? Should we split > > uuid up by creating a seperate directory with Makefile etc. or > > will a symlink to libuuid do? > > I think we should create a separate library. I'm also wondering if we > shouldn't move them to dlls/, these are more like import libs than > normal Unix libs. I explored that possibility some time ago. Moving to dlls/ implies using a spec file, because I don't think we want to use anything other than a standard Makefile under dlls/, right? This puzzled me since uuids are not functions and although spec syntax allows specification of data entry points ('extern'), winebuild doesn't support importing them. Using the standard Makefile will also give us a DSO which we don't need. -Hans

Jan. 16, 2004

Re: DOS: fix loading of DOS exe files

by Michael Stefaniuc

Hello, Alexandre please don't apply this patch. Ove told me why the hack is in. I'll redo the patch. bye michael On Fri, Jan 16, 2004 at 02:43:16AM +0100, Michael Stefaniuc wrote: > the attached patch fixes a problem when loading DOS exe files which have > 4 bytes on the last page of the executable. There is no comment in the > code and i googled and couldn't find any reason or hint why having 4 > bytes on the last page is special and why we should than load the full > 512 bytes of the last page (i'm CC'ing wine-devel just in case). This > prevents some of the "PC Intern 4, Systemprogrammierung" DOS example > files from running with an 'invalid exe file' error. > > License: LGPL, X11 > Changelog: > Michael Stefaniuc <mstefani(a)redhat.com> > - do not load the full last page of a DOS EXE if we have only 4 > bytes in it. -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Jan. 16, 2004

Re: Add iccvid.spec to winapi_check

by Hans Leidekker

On Thursday 15 January 2004 19:21, Alexandre Julliard wrote: > > After DLL separation is complete, adding these will no > > longer be necessary, right? > > Well, it's really winapi_check that needs to be made smarter. 99% of > the contents of that file are redundant already and could be > determined automatically. Yes, that's what I was aiming at. All it seems to add is grouping of files under a module, which is implied when DLL separation is complete. Then it would simply be a matter of doing: find dlls/ -name "*.spec" or some equivalent of that, and we can get rid of synchronizing winapi_check by hand. -Hans

Jan. 16, 2004

Re: Try using the Mozilla Active X control in MSHTML

by Vincent Béron

Le ven 16/01/2004 à 01:23, Dimitrie O. Paun a écrit : > On January 16, 2004 01:06 am, Mike McCormack wrote: > > Since some people have been complaining that MSHTML is a useless > > distraction in it's current form (there's some element of truth in > > that), here's a small patch to redirect calls to Mozilla's Active X > > control. You need to add a "mshtml"="builtin,native" override in the > > config file and download and install the control before this patch can > > try to use it: > > > > http://www.iol.ie/~locka/mozilla/control.htm > > Very nice Mike! I guess this requires a Win32 build of Mozilla, no? > Anyway, if the patch goes in, it would be nice if our good packagers > can come up with a binary package (say, wine-mozilla?) that just > installs alongside with the wine package and provides this capability. The ActiveX control listed at the listed address is self-contained (but still 5MB in size), so it's probably not much work to package it as well. Don't know when I could try something about it though, since Mozilla 1.6 has just been released and I'm involved with the French translation. And Alexandre still hasn't committed it yet :P Vincent

Jan. 16, 2004

Re: Try using the Mozilla Active X control in MSHTML

by Dimitrie O. Paun

On January 16, 2004 01:06 am, Mike McCormack wrote: > Since some people have been complaining that MSHTML is a useless > distraction in it's current form (there's some element of truth in > that), here's a small patch to redirect calls to Mozilla's Active X > control. You need to add a "mshtml"="builtin,native" override in the > config file and download and install the control before this patch can > try to use it: > > http://www.iol.ie/~locka/mozilla/control.htm Very nice Mike! I guess this requires a Win32 build of Mozilla, no? Anyway, if the patch goes in, it would be nice if our good packagers can come up with a binary package (say, wine-mozilla?) that just installs alongside with the wine package and provides this capability. -- Dimi.

Jan. 16, 2004

Re: Implement LockWindowUpdate [take 3]

by Alexandre Julliard

Mike Hearn <mike(a)theoretic.com> writes: > I hit Google and found a page describing how to reduce flickering in > FrontPage by writing a utility VB app using LockWindowUpdate and > FindWindow, so clearly my initial implementation was wrong and this does > need server support. The resultant code is also cleaner I feel. Yes it's much better. Now the problem is that the rest of the code won't be able to cope with it: in order to make sure painting always happens correctly, you will need to invalidate all the DCEs concerned by the window, to make sure all the update regions are recomputed correctly. Unfortunately this can't be done inter-process at the moment... -- Alexandre Julliard julliard(a)winehq.com

Jan. 16, 2004

Re: Partial MDI rewrite

by Dmitry Timoshkov

"Duane Clark" <dclark(a)akamail.com> wrote: > > Could you please generate +win,+mdi logs before and after the patch > > and send them to me? > > > > They are a bit large, but here goes. Thank you very much. Now I see that I unintentionally omitted a bit of code dealing with cx or cy being CW_USEDEFAULT[16]. Attached patch should have it fixed. -- Dmitry.

Jan. 16, 2004

Re: win3.1 printer drivers

by Alexandre Julliard

"Ivan Leo Murray-Smith" <puoti(a)inwind.it> writes: > Are win3.1 printer driver still supported by wine? No, that code has been removed since it is incompatible with a 32-bit GDI. -- Alexandre Julliard julliard(a)winehq.com

Jan. 16, 2004

Re: More Vacation backlog

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Alexandre: > > Do I understand your last sentence right? > > server/device.c should disapear? Yes, it's a temporary hack. Devices should be normal file handles. Eric's file management patch is going to take care of that I believe. -- Alexandre Julliard julliard(a)winehq.com

Jan. 16, 2004

Re: Partial MDI rewrite

by Dmitry Timoshkov

"Duane Clark" <dclark(a)akamail.com> wrote: > In the window titled "Array1", if I double click one of those blue > rectangles, another window should pop up (showing the contents of the > blue rectangle). The window does pop up; it is the one labelled "Block". > But it comes up "minimized" (sort of), which it shouldn't. Could you please generate +win,+mdi logs before and after the patch and send them to me? Thanks. -- Dmitry.

Jan. 16, 2004

Re: Partial MDI rewrite

by Duane Clark

Dmitry Timoshkov wrote: > "Duane Clark" <dclark(a)akamail.com> wrote: > > >>With Xilinx fpga editor, I see one problem. When I double click one of >>the blue squares in the array window, a block window shows up. But with >>the patch, it is showing up sort of minimized, as shown. > > > Thanks for the testing. But what do you mean by "the blue squares in > the array window"? > Oops, I guess that was very unclear. I was referring to the blue rectangles with wires going into them, like the ones just below the window titled "Block". In the window titled "Array1", if I double click one of those blue rectangles, another window should pop up (showing the contents of the blue rectangle). The window does pop up; it is the one labelled "Block". But it comes up "minimized" (sort of), which it shouldn't.

Jan. 16, 2004

Re: Partial MDI rewrite

by Dmitry Timoshkov

"Duane Clark" <dclark(a)akamail.com> wrote: > With Xilinx fpga editor, I see one problem. When I double click one of > the blue squares in the array window, a block window shows up. But with > the patch, it is showing up sort of minimized, as shown. Thanks for the testing. But what do you mean by "the blue squares in the array window"? -- Dmitry.

Jan. 16, 2004

DOS: fix loading of DOS exe files

by Michael Stefaniuc

Hello, the attached patch fixes a problem when loading DOS exe files which have 4 bytes on the last page of the executable. There is no comment in the code and i googled and couldn't find any reason or hint why having 4 bytes on the last page is special and why we should than load the full 512 bytes of the last page (i'm CC'ing wine-devel just in case). This prevents some of the "PC Intern 4, Systemprogrammierung" DOS example files from running with an 'invalid exe file' error. License: LGPL, X11 Changelog: Michael Stefaniuc <mstefani(a)redhat.com> - do not load the full last page of a DOS EXE if we have only 4 bytes in it. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Jan. 16, 2004

Regression tests and Paul Millars WRT

by Mike Hearn

So, I saw in WWN mention of this website which I stumbled across by accident a few weeks ago, and had another look. I couldn't believe how useful it was, yet nobody seemed to use it and it's not a part of WineHQ. A few questions, therefore: 1) Firstly, to Paul - could you hook things up so that when we get new red/purple builds an email is sent to wine-devel? I just sent a patch to fix the http tests that started failing but I wouldn't have seen it if it was not for your system. I think Alexandre runs the test suite before checking in each patch, but it's still possible that there are ones he misses (like this). If it was being done automatically perhaps AJ would not need to run the whole test suite before each commit, so he could work faster as well (and alexandre-cycles are waaaaay more valuable than cpu-cycles :) 2) Why is this not running on a WineHQ machine? Too expensive? Not needed? 3) Is the source to WRT available anywhere? thanks -mike

Jan. 15, 2004

Re: Partial MDI rewrite

by Duane Clark

Dmitry Timoshkov wrote: > Hello all, > > here is a result of my work aimed to merge MDI child creation > with common window creation code. The rewrite allows MDI children > to have WS_EX_MDICHILD style set on WM_CREATE and therefore properly > get lParam from MDICREATESTRUCT. MDICREATESTRUCT is now gets A<->W > translated (translation 16-bit windows is still missing). > > Please give it a try with your favorite MDI application and report > the results you get. With Xilinx fpga editor, I see one problem. When I double click one of the blue squares in the array window, a block window shows up. But with the patch, it is showing up sort of minimized, as shown.

Jan. 15, 2004