- wine-devel - winehq.org

Re: List other downloads on winehq
by Ivan Leo Murray-Smith 20 Apr '04

20 Apr '04

> But since you have not agreed to any license, you are free to personally > use your download however you wish. Thanks to the new EU laws on copyright (Not the patent one, this is another thing), this will soon change. Ivan.

2 1

Appdb - Add submit time to appQueue
by Chris Morgan 20 Apr '04

20 Apr '04

* appsubmit.php, admin/adminAppQueue.php, tables/appdb_tables.sql Chris Morgan <cmorgan(a)alum.wpi.edu> It would be nice to know when entries to the appdb were submitted. Jeremy, you'll want to run this alter command to add the column to the existing table. 'alter table appQueue add column submitTime timestamp;' Comments? Chris

2 1

A Few Newbie questions
by Lonnie Cumberland 20 Apr '04

20 Apr '04

Hello All, I have been watching Wine grow over a period of time and it looks like things are getting better each time that I visit the site. Let me first say "GREAT JOB" to all of the developers on the project. I am wondering a few things and hope someone could take a stab at answering these for me. 1.) Is wine thread save and can I run many instances without problems? Also, can multiple users be running multiple instances without major degrades in system performance for each instance? 2.) What is the main differences between the WineX and Wine developments? Which is more stable? Thanks in advance, Lonnie.

3 2

Wine Directory Mapping sub-system
by Lonnie Cumberland 20 Apr '04

20 Apr '04

Hello All, Is there some where that I can read docs that talk about the directory mapping sub-system? In particular, I am interested in the way that you can "map" user directories in the configuration file in a users HOME directory. What I am thinking about is how one might use this same idea to "Jail" Linux user directories so that users cannot navigate out of their home directory as a security feature. Just playing with ideas, but I thought that the Wine sub-system might offer a great feature for this in that applications could not do anything even if they were to "Break" Out" as they would be going through a translation layer just like the Window applications but onlu still being Linux applications. Any ideas on this? Thanks, Lonnie

2 1

Re: Cross compile fix
by Alexandre Julliard 20 Apr '04

20 Apr '04

Hans Leidekker <hans(a)it.vu.nl> writes: > -.res.res.cross.o: > +.rc.res.cross.o: > $(CROSSWINDRES) -i $< -o $@ Why do you need that? windres should work just fine with a .res file as input. What error do you get? -- Alexandre Julliard julliard(a)winehq.org

3 4

Re: Re: [D3D8] Some vertex shaders fixes
by Christian Costa 20 Apr '04

20 Apr '04

> Message du 20/04/04 02:54 > De : Alexandre Julliard > A : Christian Costa > Copie à : wine-devel(a)winehq.org > Objet : Re: [D3D8] Some vertex shaders fixes > Christian Costa writes: > > > + if ( !RegOpenKeyA( HKEY_LOCAL_MACHINE, "Software\\Wine\\d3d", &hkey) && > > !RegQueryValueExA( hkey, "vs_mode", 0, NULL, buffer, &size) ) > > I changed the key name to "Software\Wine\Direct3D" and the value to > "VertexShaderMode", in an attempt to make it a bit less obscure for > users who stumble upon it in regedit. Good idea! :-) > Feel free to suggest other names > if you don't like these. > It's fine. :-) Christian

1 0

Re: Re Winebuild : Fix spec32 file generation for Darwin
by Alexandre Julliard 20 Apr '04

20 Apr '04

emmanuel maillard <e.rsz(a)libertysurf.fr> writes: > Sorry my previous mail include a broken patch > This one is the good one. > > Changelog : > Fix spec32 file generation for Darwin Why are you removing the init code and the SizeOfImage thing? This doesn't look right at all. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [D3D8] Some vertex shaders fixes
by Alexandre Julliard 20 Apr '04

20 Apr '04

Christian Costa <titan.costa(a)wanadoo.fr> writes: > + if ( !RegOpenKeyA( HKEY_LOCAL_MACHINE, "Software\\Wine\\d3d", &hkey) && > !RegQueryValueExA( hkey, "vs_mode", 0, NULL, buffer, &size) ) I changed the key name to "Software\Wine\Direct3D" and the value to "VertexShaderMode", in an attempt to make it a bit less obscure for users who stumble upon it in regedit. Feel free to suggest other names if you don't like these. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: d3d8 CVS brokenness?
by Ivan Leo Murray-Smith 19 Apr '04

19 Apr '04

CVS current (Read right now) works for me. Ivan.

4 4

Re: List other downloads on winehq
by Ivan Leo Murray-Smith 19 Apr '04

19 Apr '04

> In some jurisdictions... OK, in all jurisdictions that recognise the rule of law and the right of copyright holders. I'm sure you could use it in Somalia or Iraq without anybody sueing you. Ivan.

3 2

Re: appdb/. appview.php
by hatky 19 Apr '04

19 Apr '04

WTF? I think this patch needed to have the file bug.php, it is not there, there is no such file, now the link no longer work, plz fix ASAP, either revert the patch or send the file............. On Monday 19 April 2004 23:48, Jeremy Newman wrote: > ChangeSet ID: 12051 > CVSROOT: /opt/cvs-commit > Module name: appdb > Changes by: jnewman(a)wine.codeweavers.com 2004/04/19 15:48:46 > > Modified files: > . : appview.php > > Log message: > Tony Lambregts <tony_lambregts(a)telusplanet.net> > Add bug.php to better integrate AppDB with Bugzilla > > Patch: http://cvs.winehq.org/patch.py?id=12051 > > Old revision New revision Changes Path > 1.4 1.5 +1 -2 appdb/appview.php -- Hatky, Worshiper of wine (http://www.winehq.org/), Impossible is only an opinion.

3 2

List other downloads on winehq
by Vincent Béron鲯n 19 Apr '04

19 Apr '04

Following a discussion on IRC with a new user, we probably want to list on the Download page on winehq what other packages are available on sf, besides Wine per se. Also, besides DCOM95, there are a couple other Microsoft packages that people are sometimes encouraged to install to get some functionality that Wine hasn't matched yet. Does somebody have a list of what can be found (and installed on a non-Windows platform) on Microsoft's site? Vincent

3 2

Re: Widl: Conditionals, Dotted Versions, Handles
by Robert Shearman 19 Apr '04

19 Apr '04

>>> Ove Kaaven <ovek(a)arcticnet.no> 04/18/04 15:25 PM >>> lør, 17.04.2004 kl. 18.53 skrev Robert Shearman: > > Hi, > > > > This patch adds support for several features I found lacking whilst > > attempting to generate headers for RPC interfaces. > > Is this needed? > > @@ -350,6 +354,7 @@ > | tSWITCHTYPE '(' type ')' { $$ = make_attrp(ATTR_SWITCHTYPE, type_ref($3)); } > | tUUID '(' aUUID ')' { $$ = make_attrp(ATTR_UUID, $3); } > | tV1ENUM { $$ = make_attr(ATTR_V1ENUM); } > + | tVERSION '(' version '.' version ')' { $$ = make_attrv2(ATTR_VERSION, $3, $5); } > | tVERSION '(' version ')' { $$ = make_attrv(ATTR_VERSION, $3); } > | tWIREMARSHAL '(' type ')' { $$ = make_attrp(ATTR_WIREMARSHAL, type_ref($3)); } > | pointer_type { $$ = make_attrv(ATTR_POINTERTYPE, $1); } > > Doesn't the "version" rule already handle this? It would appear not. The 'version' type is declared as a number further up and when it attempts to parse a dotted version it just returns 0. Rob

2 1

Re: d3d8 CVS brokenness?
by Ivan Leo Murray-Smith 19 Apr '04

19 Apr '04

> Like several people here, I haven't been able to build from CVS for the > last few days. Maybe you haven't used -PAd when updating, or maybe you should try pulling down an entire new source tree. Or you have out of date headers. In any case whoever maintains that code will presumably read the messages on the list, and look into it. Ivan.

3 2

Re: List other downloads on winehq
by Ivan Leo Murray-Smith 19 Apr '04

19 Apr '04

You don't need windows installed at all. You only need a windows license, the EULA says you must have a valid license for the computer where you're installing IE. It doesn't matter if windows is installed or not. I got this confirmed by Microsoft. Ivan.

1 0

Re: d3d8 CVS brokenness?
by brettholcomb＠charter.net 19 Apr '04

19 Apr '04

I'm not at my machine now but I tried to build CVS yesterday (see my post) and got errors with d3d undefined variables, etc. In short I couldn't build it - is this part of the same issue? > > From: Joel Konkle-Parker <jjk3(a)msstate.edu> > Date: 2004/04/19 Mon PM 03:06:43 GMT > To: wine-devel(a)winehq.com > Subject: d3d8 CVS brokenness? > > I've noticed that d3d8 has been broken the past couple days in CVS. Is > this a work in progress that'll get fixed soon, or does it need to be > looked at? > > > -- > Joel Konkle-Parker > Webmaster [Ballsome.com] > > E-mail [jjk3(a)msstate.edu] > > >

1 0

Re: Make Unicode strings 'static const' (part 3)
by Dimitrie O. Paun 19 Apr '04

19 Apr '04

On Mon, 19 Apr 2004, Francois Gouget wrote: > As for the previous patch it's important to check that the function does > not actually try to write to these strings. And indeed there are a few > cases where the function modifies the string, typically to change the > drive letter in strings like 'A:\'. What about a list of things that weren't "const static"-ied? Maybe we should have a policy of having such string as *always* "const static" (and maybe have puk's sparse tool warn for non conforming ones), and in places where they need to modify them, they just copy them on stack explicitly... -- Dimi.

2 1

dcom95
by Ivan Leo Murray-Smith 19 Apr '04

19 Apr '04

We currently have dcom95 on the sf download page. This is a violation of the sf TOS, and a waste of bandwidth for sf. I propose we link the microsoft download page, instead of having the download on a page that should host only open source. Any objections? Ivan.

1 0

Still trying to install ZooTycoon (demo-version)
by pvriens＠xs4all.nl 19 Apr '04

19 Apr '04

Hi, I'm still trying (won't give up) to install the ZooTycoon demo from M$. Unfortunatly I've been debugging for the last weeks and cannot seem to find the cause/error/reason it fails. I'm downloading new versions from CVS daily but only seem to find other stuff :-). The installation (copying of files) stops at the point when a new background picture should be shown during the copying. I still have the feeling it all boils down to messaging. I see that all PostMessage's are done to the main thread (0009). The PeekMessage's are all done from a relevant thread, ergo : nothing found. If I look at the debug-log the only entries at the end are thousends of PeekMessage's. I also see when debugging it on windows that the PeekMessages are done from the main thread ! Does somebody have any hint how to tackle this one ? It appears that several M$ demo programs suffer the same problem, so it could be worthwile to pursue this one. Cheers, Paul.

1 0

d3d8 CVS brokenness?
by Joel Konkle-Parker 19 Apr '04

19 Apr '04

I've noticed that d3d8 has been broken the past couple days in CVS. Is this a work in progress that'll get fixed soon, or does it need to be looked at? -- Joel Konkle-Parker Webmaster [Ballsome.com] E-mail [jjk3(a)msstate.edu]

1 0

err:clipping:CLIPPING_UpdateGCRegion hVisRgn is zero. Please report this.
by Brad Campbell 19 Apr '04

19 Apr '04

G'day all, Due to restrictions in my current setup I'm not subscribed to wine-devel at the moment, please cc me. This is a longstanding bug with Word97. It exists in Crossover office 2.1.0 as well and was reported in the Codeweavers database months ago. It usually results in the "style" drop down box on the far left of the toolbar blanking it's entries. I have a pretty complex default template that has a number of styles in it that all render with funky true-type fonts. When you scroll up and down this list a couple of times, wine ceases to render the entries. It used to lock up in an endless loop somewhere, but now it bombs with the below error message. I compile from CVS a couple of times a week, and subject to time I'm happy to do anything at all to assist in debugging this if it will help someone. (I have worked around it by creating tool bars with all my styles on it so I don't have to use this box) Regards, Brad fixme:hook:NotifyWinEvent (32773,0x30035,-4,11)-stub! fixme:hook:NotifyWinEvent (32773,0x30035,-4,10)-stub! err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes fixme:hook:NotifyWinEvent (32773,0x30035,-4,9)-stub! err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes fixme:hook:NotifyWinEvent (32773,0x30035,-4,8)-stub! err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes fixme:hook:NotifyWinEvent (32773,0x30035,-4,7)-stub! err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes fixme:hook:NotifyWinEvent (32773,0x30035,-4,6)-stub! err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes fixme:hook:NotifyWinEvent (32773,0x30035,-4,5)-stub! err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes fixme:hook:NotifyWinEvent (32773,0x30035,-4,4)-stub! err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes fixme:hook:NotifyWinEvent (32773,0x30035,-4,3)-stub! err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 116 bytes fixme:hook:NotifyWinEvent (5,0x10022,-3,0)-stub! fixme:ole:I_RpcWindowProc (0x10026,0000001c,00000000,00000000): stub err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 10c7 for 28 bytes err:clipping:CLIPPING_UpdateGCRegion hVisRgn is zero. Please report this.

2 1

Re: Installing DCOM98 with latest CVS
by pvriens＠xs4all.nl 19 Apr '04

19 Apr '04

Went back to the new implementation of GetDiskFreeSpace*. This gives me the following tracing after starting 'wine dcom98.exe' with full tracing on: 0009:Call kernel32.GetDiskFreeSpaceA(00000000,406cfc40,406cfc38,406cfc3c,406cfc28) ret=01004f8a 0009:trace:volume:GetDiskFreeSpaceA (null),0x406cfc40,0x406cfc38,0x406cfc3c,0x406cfc28 0009:trace:volume:GetDiskFreeSpaceW (null),0x406cfc40,0x406cfc38,0x406cfc3c,0x406cfc28 0009:Call ntdll.RtlDosPathNameToNtPathName_U(4039d540 L"\\",406cf770,00000000,00000000) ret=40340d1e 0009:trace:file:RtlDosPathNameToNtPathName_U (L"\\",0x406cf770,(nil),(nil)) 0009:trace:file:RtlGetFullPathName_U (L"\\" 520 0x406cf488 (nil)) 0009:trace:heap:RtlAllocateHeap (0x401a0000,00000002,00000018): returning 401d6b70 0009:trace:file:RtlDosPathNameToNtPathName_U At the end, returning TRUE 0009:Ret ntdll.RtlDosPathNameToNtPathName_U() retval=00000001 ret=40340d1e 0009:Call ntdll.NtOpenFile(406cf7e8,00000000,406cf778,406cf768,00000000,00000021) ret=40340d74 0009:trace:ntdll:NtCreateFile handle=0x406cf7e8 access=00000000 name=L"\\??\\E:\\" objattr=00000040 root=(nil) sec=(nil) io=0x406cf768 alloc_size=(nil) attr=00000000 sharing=00000000 disp=1 options=00000021 ea=(nil).0x00000000 0009:trace:heap:RtlAllocateHeap (0x401a0000,00000002,00000128): returning 401d9ff0 0009:trace:heap:RtlFreeHeap (0x401a0000,00000002,401d9ff0): returning TRUE 0009:warn:ntdll:NtCreateFile L"\\??\\E:\\" not found (c000003a) Hope this helps someone with better understanding of the code. Cheers, Paul.

2 2

Re: dinput/joystick_linuxinput #2
by Christoph Frick 18 Apr '04

18 Apr '04

On Sun, Apr 18, 2004 at 09:37:07PM +0200, Christoph Frick wrote: *sic* stupid brain... License: LGPL > - added code to have the joystick state be set to the assumed center > values of the joystick mapped to the range the application wants them > - generate events after setting the apropiate values in This->js > - replaced magic ints with defines from linux/input.h > - removed mapping code that generated wrong values for axes, that have > the center on the min or max -- cu

1 0

Re: GetModuleFileName
by Juan Lang 18 Apr '04

18 Apr '04

Alexandre wrote: > I doubt it fills the buffer with nulls if it is too > large though, so strncpy is probably not the right > thing to use here (in fact strncpy is almost always > the wrong function to use, we should probably have > a janitorial task to fix this everywhere). What is the right thing? strlcpy? --Juan __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25� http://photos.yahoo.com/ph/print_splash

2 1

Re: Add a win32 hello world program
by Alexandre Julliard 18 Apr '04

18 Apr '04

Mike Hearn <mike(a)navi.cx> writes: > Mike Hearn <mike(a)navi.cx> > Add a win32 hello world program which sets up a simple window and runs > the message loop. This can be used as a starting point for test programs. I think we have already enough small winelib apps that can be used as starting points, like winver or winepath. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: GetModuleFileName
by Alexandre Julliard 18 Apr '04

18 Apr '04

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > Interestingly enough, GetModuleFileName[AW] doesn't '\0'-terminate the > buffer if it is too small > Our current implementation was terminating the buffer. > This patch fixes this, and adds a test case for that behavior and > patches all the places in wine which are potentially impacted by it I doubt it fills the buffer with nulls if it is too large though, so strncpy is probably not the right thing to use here (in fact strncpy is almost always the wrong function to use, we should probably have a janitorial task to fix this everywhere). -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: dlls/kernel/console.c::SetConsoleCtrlHandler() cleanup/fixup
by Alexandre Julliard 18 Apr '04

18 Apr '04

Peter Riocreux <par+wine_devel(a)silistix.com> writes: > It gives every impression of working for me, but I have only tested it > with one application. > > Suggestions for better extended error codes appreciated. Error codes should not be based on suggestions, what you should do is write a small test program under Windows to find out the real codes. -- Alexandre Julliard julliard(a)winehq.org

9 16

Re: msvcrt
by Uwe Bonnes 18 Apr '04

18 Apr '04

>>>>> "Eric" == Eric Pouech <pouech-eric(a)wanadoo.fr> writes: Eric> I was about to implement the fd inheritance in msvcrt, when I came Erich, the attachment seems broken again... -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 2

Re: List other downloads on winehq
by Ivan Leo Murray-Smith 18 Apr '04

18 Apr '04

> Internet Explorer ..... Installing IE requires a windows license for the computer where you're installing it. This sort of restricts it's use with wine. Ivan.

2 1

arch tip #2
by Mike Hearn 18 Apr '04

18 Apr '04

Hi everyone, I just checked in a new update to the genpatch script. It can now send an email to wine-patches automatically given a set of local changesets. Use it like this: ./genpatch -m 5 6 7 if you did three commits, patch-5, patch-6 and patch-7 and want to send them all to wine-patches as one email. The log message and summary of the first patch will be used, and all three patches will be combined into one. You get to edit the email before it's sent and will be asked for confirmation, so you can read it over one last time. By default it will send mail to localhost - if you don't want to setup sendmail you can have "export GENPATCH_RELAY=smtp.myisp.com" in your shell init scripts to make it use a different mail relay. So in summary, development on a series of related improvements to wine goes like this: (setup arch and checkout the cvs gateway tree) ./branch some-branch cd .. cd some-branch tla make-log (make some changes, noting what they are in the arch-created log file as you go) tla commit * committed whoever(a)where-ever.org--2004/wine--some-branch--0.9--patch-2 tla make-log (more changes) tla commit * committed whoever(a)where-ever.org--2004/wine--some-branch--0.9--patch-3 ./merge (this brings your tree up to date with winehq, only bother if you think there has been enough drift to make it worthwhile) ./genpatch -m 2 3 (read generated email, to confirm delete the first line + save + quit) thanks -mike

1 0

Security of WINE and ReactOS: was Documents and settings
by Steven Edwards 18 Apr '04

18 Apr '04

Hello Alex, I am going to drag this semi-off topic for a bit while I plant some ideas in people heads. --- Aleksey Bragin <aleksey(a)studiocerebral.com> wrote: > If ROS will support (and I bet it will!) NT 4.0 security model (or, > better, > Win2k then) it would be just great! > Certainly people with deeper knowledge of this security model + > knowledge of > unix and also linux implementation model can specify the differences, > and > what's missing in them. Note I only know a little about the Local Securty Authority but I think its not going to be to hard to implement if Wine and ReactOS work together on it. /me just doubts how much he can write. The unix security design of users and groups with permissions is not bad its just outdated. The nice thing about Unix is adding new security modules via PAM is not to bad except they are only for authentication. The unix concept of groups, users and permissions needs to be moved forward about 20 years. The SELinux stuff has really helped alot in this regard. (Please dont flame its the truth) I recently addressed this in a discussion about ReactOS. Currently our lsass does not exist. I think we have what we have parts of the security reference monitor already implemented in ntoskrnl and most of the parts are there for winlogon and the SAM database so we need to develop the lsass services and build out the authentaticaion modules for MSV1_0 auth. One of the nice things about the design of the Windows security module is that we can make plugins at both ends so that users can be granted access either based on a "domain" concept in winlogin/Gina using plugins for LDAP and PAM or via the lsass so users can be authencated locally. It would be nice if we could work with the Winehq people on this as I think we can share the parts of the security subsystem that reside in lsass. Think of it like this (Kernel support) wineserver/ntosknrl need to both implement the security refernce montior for privlaged use of the local system resources. I dont know how much of this wineserver really needs to take in to account in the initial incarnation. (Local security subsystem) Lsass works interactivly with services and the login system and can accept all sorts of nice plugins so we are not limited to just the standard Windows authentication. As a matter of fact you could replace large parts of they authentication system if you are supper paronoid. Think of lsass as the sentry for Windows. It talks to the SRM to make sure you are not doing anything you shouldnt be. (User interaction) Interaction with the user will come from Winlogon on ReactOS or on Unix the user should already be authenticated via Linux security. This can of course be done via the authentication modules described above. Once the user I wish I could attach the nice chart from Inside Windows NT so you could see the security subsystem. Its quite a piece of work and is quite a shame Windows security gets a bad name due to slack administrators. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html

4 3

Installing DCOM98 with latest CVS
by pvriens＠xs4all.nl 18 Apr '04

18 Apr '04

Hi, I was trying to install dcom98.exe with the latest CVS and run into several errors ranging from file-not-found errors upto problems with getting the free diskspace of drives. Tracing showed (amongst others): trace:file:GetLongPathNameW L"E:\\TOOLS",0x406cf144,1024 trace:file:RtlDosPathNameToNtPathName_U (L"E:\\TOOLS",0x406cde4c,0x406cde54,(nil)) trace:file:RtlGetFullPathName_U (L"E:\\TOOLS" 520 0x406cdc08 0x406cde54) trace:file:RtlDosPathNameToNtPathName_U At the end, returning TRUE trace:file:GetLongPathNameW not found L"E:\\TOOLS"! so we didn't get an handle from RtlDosPathNameToNtPathName_U ! After some extra tracing I decided to revert some patches and got this installation working after reverting the following patches: http://cvs.winehq.org/cvsweb/wine/dlls/kernel/volume.c.diff?r1=1.7&r2=1.8 log : Reimplemented GetDiskFreeSpaceW and GetDiskFreeSpaceExW http://cvs.winehq.org/cvsweb/wine/dlls/kernel/change.c.diff?r1=1.4&r2=1.5 log : Make FindFirstFileExW and FindFirstChangeNotificationW use NtOpenFile directly http://cvs.winehq.org/cvsweb/wine/files/drive.c.diff?r1=1.114&r2=1.115 log : Reimplemented GetDiskFreeSpaceW and GetDiskFreeSpaceExW I will investigate further, but just to let you know. I didn't try other programs. Everything done on a clean non-windows installation. Cheers, Paul.

1 0

Re: Widl: Conditionals, Dotted Versions, Handles
by Ove Kaaven 18 Apr '04

18 Apr '04

lør, 17.04.2004 kl. 18.53 skrev Robert Shearman: > Hi, > > This patch adds support for several features I found lacking whilst > attempting to generate headers for RPC interfaces. Is this needed? @@ -350,6 +354,7 @@ | tSWITCHTYPE '(' type ')' { $$ = make_attrp(ATTR_SWITCHTYPE, type_ref($3)); } | tUUID '(' aUUID ')' { $$ = make_attrp(ATTR_UUID, $3); } | tV1ENUM { $$ = make_attr(ATTR_V1ENUM); } + | tVERSION '(' version '.' version ')' { $$ = make_attrv2(ATTR_VERSION, $3, $5); } | tVERSION '(' version ')' { $$ = make_attrv(ATTR_VERSION, $3); } | tWIREMARSHAL '(' type ')' { $$ = make_attrp(ATTR_WIREMARSHAL, type_ref($3)); } | pointer_type { $$ = make_attrv(ATTR_POINTERTYPE, $1); } Doesn't the "version" rule already handle this?

1 0

Re: List other downloads on winehq
by Ivan Leo Murray-Smith 18 Apr '04

18 Apr '04

> Does somebody have a list of what can be > found (and installed on a non-Windows platform) on Microsoft's site? It's not a complete list, but I've got the following links vb runtime http://www.microsoft.com/downloads/details.aspx?FamilyID=bf9a24f9-b5c5-48f4… the windows installer for win9x http://www.microsoft.com/downloads/details.aspx?FamilyID=cebbacd8-c094-4255… the windows installer for winnt/2k http://www.microsoft.com/downloads/details.aspx?FamilyID=4b6140f9-2d36-4977… The comctl32 dll, the eula says you can only distribute it with an app that runs on windows, but it also says you can use it, and doesn't say that to do so you need a windows license (The eula is the same one you get with the sdk), so it's ok to use it on wine. http://www.microsoft.com/downloads/details.aspx?FamilyID=6f94d31a-d1e0-4658… gdi+ components, same license as comctl32 http://www.microsoft.com/downloads/details.aspx?FamilyID=bfc0b436-9015-43e2… CAPICOM.DLL http://www.microsoft.com/downloads/details.aspx?FamilyID=860ee43a-a843-462f… ShFolder DLL http://www.microsoft.com/downloads/details.aspx?FamilyID=6ae02498-07e9-48f1… I think all these windows components can be used without problems on wine, but probably winehq can't redistribute any of them. BTW, we have dcom95 on the sourceforge page, this is a violation of the sf TOS, wouldn't it be a good idea to link to the microsoft dcom95 download page instead? Like this we'll user their bandwidth, and save a little for sf.net. Ivan.

1 0

Re: (no subject)
by Ivan Leo Murray-Smith 18 Apr '04

18 Apr '04

> If not, I would like to give it a try, but I need some > documentation c.q. information on the functionallity > of these functions /what they do etc http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/wi… Ivan.

1 0

Change to CompareStringW introduced regression in QuArK (bug #2159)
by David Costanzo 18 Apr '04

18 Apr '04

I have been investigating a regression in the functionality of QuArK, a popular level editor for Quake. The regression is filed as bug #2159. I have identified the cause of the regression as changes made to CompareStringW from revision 1.25 to revision 1.26 of wine/dlls/kernel/locale.c. I do not know how to proceed from here. The relevant modification is changing CompareStringW from calling strncmpiW/strncmpW to calling wine_compare_string. I hacked my code to call both the new and old version and print out whenever the two return different values. Calling wine_compare_string seems to have changed the behavior of comparing strings that have accent marks with strings that don't have accent marks when the NORM_IGNORECASE flag is set. I don't understand unicode collation, nor do I know how QuArK is using CompareStringW. I don't doubt that CompareStringW should call wine_compare_string, but if this is a bug in wine_compare_string, I don't know how to fix it. Does anyone have any suggestions on what my next step should be? Thanks, David Costanzo __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25� http://photos.yahoo.com/ph/print_splash

1 0

Re: [D3D8] Fix on Hardware Vertex Shaders and D3DTADDRESS_MIRROR
by Lionel Ulmer 18 Apr '04

18 Apr '04

> - fix the SetTextureStageState for D3DTADDRESS_MIRROR using dynamic GL > detection (and not build time GL headers) By the way, you should also check for the 'GL_IBM_texture_mirrored_repeat' extension. I know of no OpenGL drivers who has the IBM and not the ARB extension, but well, it does cost nothing to be pedantic :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

RE: Security of WINE and ReactOS: was Documents and settings
by Joshua Walker 18 Apr '04

18 Apr '04

The one known as "Steven Edwards" hath scripted: --------------------------------- The unix security design of users and groups with permissions is not bad its just outdated. The nice thing about Unix is adding new security modules via PAM is not to bad except they are only for authentication. The unix concept of groups, users and permissions needs to be moved forward about 20 years. The SELinux stuff has really helped alot in this regard. (Please dont flame its the truth) ----------------------------------- Looking at security from a Unix up to windows through WINE as opposed to looking down to UNIX from Windows through WINE, I have do disagree. The UNIX security system is not really "outdated" just "diffrent". One of the reasons why it's still around after 20 years is because it works. As I have never owned Windows after ME drug it's carcass across the computing landscape, I don't really quite grok windws security anyway. From futzing with an XP box at work, I don't see any real obvious way of locking down permissions on files and such. Right click/properties on a file gives me the same tierd DOS flags that haven't changed since DOS 3.0 I don't see anyting that's blocking me from deleting, say, advapi32.dll with extreame prejudice. If I went into my /lib dir and tried a rm -fr as a normal user, my system will kindly tell me to go away and play in my /home directory. The question is quite intresting. How does one "translate" a security philosophy? Do we want to give WINE the ability to hijack wsock32.dll? (wsock32.dll.so) This is often done with ISP proprietary installers, *COUGH*-AOL-*COUGH*, and various spyware apps. Has this been considered?

2 1

(no subject)
by Robbert Xerox 17 Apr '04

17 Apr '04

hi, I'm wondering if anybody is working on the WSALookupServiceBegin functions in winsock (socket.c) . If not, I would like to give it a try, but I need some documentation c.q. information on the functionallity of these functions /what they do etc. Any help appreciated. Robbert ____________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html

1 0

[PATCH?] Finally found a solution to serial port writes
by Geoffrey Hausheer 17 Apr '04

17 Apr '04

The following patch is probably wrong, but it fixes my problem with WriteFile failing when writing to a COM port. The problem appears to be that NtWaitForSingleObject sends a count of '1' which results in the wine_server_call in NTDLL_wait_for_multiple_objects returning 'STATUS_USER_APC' which aborts the execution before 'call_apcs' gets called (which actually does the write). calling 'NTDLL_wait_for_multiple_objects' with count = 0 allows the 'call_apcs' function to get called, and TzMax50 actually works perfectly (along with my nasty hack to allow the menus to work) as a reminder, the COM port is opened in non-overlapped mode, and all timeouts are set to 0. (I didn't submit this to wine-patches, since i'm not at all sure it is generally correct) I can also try to write a test-case that shows this works (sort of...I can test that WriteFile returns the right result, but not that data was actually written on the serial port. I know of no way to do that without external hardware). I don't know how to make it general enough though (what to do when there is no COM port attached to the machine?) .Geoff --- orig/dlls/ntdll/file.c +++ mod/dlls/ntdll/file.c @@ -585,7 +585,7 @@ ret = register_new_async(&ovp->async); if (ret != STATUS_SUCCESS) return ret; - if (flags & FD_FLAG_TIMEOUT) + if (hEvent != NULL && flags & FD_FLAG_TIMEOUT) { NtWaitForSingleObject(hEvent, TRUE, NULL); NtClose(hEvent);

1 0

WININET: make WCHAR strings const where possible
by Mike McCormack 17 Apr '04

17 Apr '04

"Dmitry Timoshkov" <dmitry(a)baikal.ru> wrote: > It would be much better if you could mark all string constants > as such using 'const' key word in all your patches (including > already committed, submitted and future ones). Perhaps we should make a janitorial task to CONST-ify strings where possible? Mike ChangeLog: * make WCHAR strings const where possible Index: dlls/wininet/http.c =================================================================== RCS file: /home/wine/wine/dlls/wininet/http.c,v retrieving revision 1.56 diff -u -r1.56 http.c --- dlls/wininet/http.c 31 Mar 2004 20:09:54 -0000 1.56 +++ dlls/wininet/http.c 12 Apr 2004 14:12:48 -0000 @@ -470,8 +470,8 @@ { UINT len; LPWSTR in, out; - WCHAR szBasic[] = {'B','a','s','i','c',' ',0}; - WCHAR szColon[] = {':',0}; + const WCHAR szBasic[] = {'B','a','s','i','c',' ',0}; + const WCHAR szColon[] = {':',0}; len = lstrlenW( username ) + 1 + lstrlenW ( password ) + 1; in = HeapAlloc( GetProcessHeap(), 0, len*sizeof(WCHAR) ); @@ -504,7 +504,7 @@ { HTTPHEADERW hdr; INT index; - WCHAR szProxyAuthorization[] = { + const WCHAR szProxyAuthorization[] = { 'P','r','o','x','y','-','A','u','t','h','o','r','i','z','a','t','i','o','n',0 }; hdr.lpszValue = HTTP_EncodeBasicAuth( username, password ); @@ -538,10 +538,9 @@ WCHAR proxy[MAXHOSTNAME + 15]; /* 15 == "http://" + sizeof(port#) + ":/\0" */ WCHAR* url, szNul[] = { 0 }; URL_COMPONENTSW UrlComponents; - WCHAR szHttp[] = { 'h','t','t','p',':','/','/',0 }, szSlash[] = { '/',0 } ; - /*WCHAR szColon[] = { ':',0 }; */ - WCHAR szFormat1[] = { 'h','t','t','p',':','/','/','%','s',':','%','d',0 }; - WCHAR szFormat2[] = { 'h','t','t','p',':','/','/','%','s',':','%','d',0 }; + const WCHAR szHttp[] = { 'h','t','t','p',':','/','/',0 }, szSlash[] = { '/',0 } ; + const WCHAR szFormat1[] = { 'h','t','t','p',':','/','/','%','s',':','%','d',0 }; + const WCHAR szFormat2[] = { 'h','t','t','p',':','/','/','%','s',':','%','d',0 }; int len; memset( &UrlComponents, 0, sizeof UrlComponents ); @@ -607,7 +606,7 @@ LPWSTR lpszUrl = NULL; DWORD nCookieSize; HINTERNET handle; - WCHAR szUrlForm[] = {'h','t','t','p',':','/','/','%','s',0}; + const WCHAR szUrlForm[] = {'h','t','t','p',':','/','/','%','s',0}; DWORD len; TRACE("--> \n"); @@ -670,7 +669,7 @@ if (NULL == lpszVerb) { - WCHAR szGet[] = {'G','E','T',0}; + const WCHAR szGet[] = {'G','E','T',0}; lpwhr->lpszVerb = WININET_strdupW(szGet); } else if (strlenW(lpszVerb)) @@ -698,7 +697,7 @@ if (hIC->lpszAgent) { WCHAR *agent_header; - WCHAR user_agent[] = {'U','s','e','r','-','A','g','e','n','t',':',' ','%','s','\r','\n',0 }; + const WCHAR user_agent[] = {'U','s','e','r','-','A','g','e','n','t',':',' ','%','s','\r','\n',0 }; len = strlenW(hIC->lpszAgent) + strlenW(user_agent); agent_header = HeapAlloc( GetProcessHeap(), 0, len*sizeof(WCHAR) ); @@ -716,8 +715,8 @@ if (InternetGetCookieW(lpszUrl, NULL, NULL, &nCookieSize)) { int cnt = 0; - WCHAR szCookie[] = {'C','o','o','k','i','e',':',' ',0}; - WCHAR szcrlf[] = {'\r','\n',0}; + const WCHAR szCookie[] = {'C','o','o','k','i','e',':',' ',0}; + const WCHAR szcrlf[] = {'\r','\n',0}; lpszCookies = HeapAlloc(GetProcessHeap(), 0, (nCookieSize + 1 + 8)*sizeof(WCHAR)); @@ -789,9 +788,9 @@ LPHTTPHEADERW lphttpHdr = NULL; BOOL bSuccess = FALSE; LPWININETHTTPREQW lpwhr; - WCHAR szFmt[] = { '%','s',':',' ','%','s','%','s',0 }; - WCHAR szcrlf[] = { '\r','\n',0 }; - WCHAR sznul[] = { 0 }; + const WCHAR szFmt[] = { '%','s',':',' ','%','s','%','s',0 }; + const WCHAR szcrlf[] = { '\r','\n',0 }; + const WCHAR sznul[] = { 0 }; if (TRACE_ON(wininet)) { #define FE(x) { x, #x } @@ -1419,12 +1418,12 @@ do { - WCHAR szSlash[] = { '/',0 }; - WCHAR szSpace[] = { ' ',0 }; - WCHAR szHttp[] = { 'h','t','t','p',':','/','/', 0 }; - WCHAR szcrlf[] = {'\r','\n', 0}; - WCHAR sztwocrlf[] = {'\r','\n','\r','\n', 0}; - WCHAR szSetCookie[] = {'S','e','t','-','C','o','o','k','i','e',0 }; + const WCHAR szSlash[] = { '/',0 }; + const WCHAR szSpace[] = { ' ',0 }; + const WCHAR szHttp[] = { 'h','t','t','p',':','/','/', 0 }; + const WCHAR szcrlf[] = {'\r','\n', 0}; + const WCHAR sztwocrlf[] = {'\r','\n','\r','\n', 0}; + const WCHAR szSetCookie[] = {'S','e','t','-','C','o','o','k','i','e',0 }; TRACE("Going to url %s %s\n", debugstr_w(lpwhr->lpszHostName), debugstr_w(lpwhr->lpszPath)); loop_next = FALSE; @@ -1540,7 +1539,7 @@ { if (lpwhr->StdHeaders[i].wFlags & HDR_ISREQUEST) { - WCHAR szFmt[] = { '\r','\n','%','s',':',' ','%','s', 0}; + const WCHAR szFmt[] = { '\r','\n','%','s',':',' ','%','s', 0}; cnt += sprintfW(requestString + cnt, szFmt, lpwhr->StdHeaders[i].lpszField, lpwhr->StdHeaders[i].lpszValue); TRACE("Adding header %s (%s)\n", @@ -1554,7 +1553,7 @@ { if (lpwhr->pCustHeaders[i].wFlags & HDR_ISREQUEST) { - WCHAR szFmt[] = { '\r','\n','%','s',':',' ','%','s', 0}; + const WCHAR szFmt[] = { '\r','\n','%','s',':',' ','%','s', 0}; cnt += sprintfW(requestString + cnt, szFmt, lpwhr->pCustHeaders[i].lpszField, lpwhr->pCustHeaders[i].lpszValue); TRACE("Adding custom header %s (%s)\n", @@ -1565,7 +1564,7 @@ if (lpwhr->lpszHostName) { - WCHAR szFmt[] = { '%','s','%','s',0 }; + const WCHAR szFmt[] = { '%','s','%','s',0 }; cnt += sprintfW(requestString + cnt, szFmt, HTTPHOSTHEADER, lpwhr->lpszHostName); } @@ -1658,7 +1657,7 @@ { LPHTTPHEADERW setCookieHeader; int nPosStart = 0, nPosEnd = 0, len; - WCHAR szFmt[] = { 'h','t','t','p',':','/','/','%','s','/',0}; + const WCHAR szFmt[] = { 'h','t','t','p',':','/','/','%','s','/',0}; setCookieHeader = &lpwhr->pCustHeaders[CustHeaderIndex]; @@ -1678,7 +1677,7 @@ /* fixme: not case sensitive, strcasestr is gnu only */ int nDomainPosEnd = 0; int nDomainPosStart = 0, nDomainLength = 0; - WCHAR szDomain[] = {'d','o','m','a','i','n','=',0}; + const WCHAR szDomain[] = {'d','o','m','a','i','n','=',0}; LPWSTR lpszDomain = strstrW(&setCookieHeader->lpszValue[nPosEnd], szDomain); if (lpszDomain) { /* they have specified their own domain, lets use it */ @@ -1952,8 +1951,8 @@ BOOL bSuccess = FALSE; INT rc = 0; WCHAR value[MAX_FIELD_VALUE_LEN], field[MAX_FIELD_LEN]; - WCHAR szStatus[] = {'S','t','a','t','u','s',0}; - WCHAR szHttp[] = { 'H','T','T','P',0 }; + const WCHAR szStatus[] = {'S','t','a','t','u','s',0}; + const WCHAR szHttp[] = { 'H','T','T','P',0 }; char bufferA[MAX_REPLY_LEN]; TRACE("-->\n"); @@ -2087,32 +2086,32 @@ INT HTTP_GetStdHeaderIndex(LPCWSTR lpszField) { INT index = -1; - WCHAR szContentLength[] = { + const WCHAR szContentLength[] = { 'C','o','n','t','e','n','t','-','L','e','n','g','t','h',0}; - WCHAR szStatus[] = {'S','t','a','t','u','s',0}; - WCHAR szContentType[] = { + const WCHAR szStatus[] = {'S','t','a','t','u','s',0}; + const WCHAR szContentType[] = { 'C','o','n','t','e','n','t','-','T','y','p','e',0}; - WCHAR szLastModified[] = { + const WCHAR szLastModified[] = { 'L','a','s','t','-','M','o','d','i','f','i','e','d',0}; - WCHAR szLocation[] = {'L','o','c','a','t','i','o','n',0}; - WCHAR szAccept[] = {'A','c','c','e','p','t',0}; - WCHAR szReferer[] = { 'R','e','f','e','r','e','r',0}; - WCHAR szContentTrans[] = { 'C','o','n','t','e','n','t','-', + const WCHAR szLocation[] = {'L','o','c','a','t','i','o','n',0}; + const WCHAR szAccept[] = {'A','c','c','e','p','t',0}; + const WCHAR szReferer[] = { 'R','e','f','e','r','e','r',0}; + const WCHAR szContentTrans[] = { 'C','o','n','t','e','n','t','-', 'T','r','a','n','s','f','e','r','-','E','n','c','o','d','i','n','g',0}; - WCHAR szDate[] = { 'D','a','t','e',0}; - WCHAR szServer[] = { 'S','e','r','v','e','r',0}; - WCHAR szConnection[] = { 'C','o','n','n','e','c','t','i','o','n',0}; - WCHAR szETag[] = { 'E','T','a','g',0}; - WCHAR szAcceptRanges[] = { + const WCHAR szDate[] = { 'D','a','t','e',0}; + const WCHAR szServer[] = { 'S','e','r','v','e','r',0}; + const WCHAR szConnection[] = { 'C','o','n','n','e','c','t','i','o','n',0}; + const WCHAR szETag[] = { 'E','T','a','g',0}; + const WCHAR szAcceptRanges[] = { 'A','c','c','e','p','t','-','R','a','n','g','e','s',0 }; - WCHAR szExpires[] = { 'E','x','p','i','r','e','s',0 }; - WCHAR szMimeVersion[] = { + const WCHAR szExpires[] = { 'E','x','p','i','r','e','s',0 }; + const WCHAR szMimeVersion[] = { 'M','i','m','e','-','V','e','r','s','i','o','n', 0}; - WCHAR szPragma[] = { 'P','r','a','g','m','a', 0}; - WCHAR szCacheControl[] = { + const WCHAR szPragma[] = { 'P','r','a','g','m','a', 0}; + const WCHAR szCacheControl[] = { 'C','a','c','h','e','-','C','o','n','t','r','o','l',0}; - WCHAR szUserAgent[] = { 'U','s','e','r','-','A','g','e','n','t',0}; - WCHAR szProxyAuth[] = { + const WCHAR szUserAgent[] = { 'U','s','e','r','-','A','g','e','n','t',0}; + const WCHAR szProxyAuth[] = { 'P','r','o','x','y','-', 'A','u','t','h','e','n','t','i','c','a','t','e', 0};

4 7

Re: some more dbghelp fixes & enhancements
by Dimitrie O. Paun 17 Apr '04

17 Apr '04

On April 17, 2004 3:02 pm, Eric Pouech wrote: > change log says it all > A+ > @@ -29,22 +29,21 @@ > > /* TODO The patch is b0rken. -- Dimi.

2 1

Visual FoxPro
by Cecil Champenois 17 Apr '04

17 Apr '04

I have heard that there is a lot of interest in moving the WINE for Visual FoxPro forward. About a year ago, a major FoxPro developer by the name of Whil Hentzen was telling our User Group www.ocfox.org about the Visual FoxPro work you are doing with WINE. He also demonstrated Visual FoxPro working on a Linux laptop. We were all very impressed by this and anted to jump right into development but were told that the conversion or whatever you want to call it was at least 1 to 1.5 years away. This discouraged us a bit, so what we'd like to know is this: Where does the WINE work in relation to VFP 6, 76 and 8 stand now? We would like to begin some development in Linux, but need to know where the WINE work stands at this time and what the future looks like. Cecil

3 2

RE: Proposed solution for COMCTL32 subclassing problems
by Robert Shearman 17 Apr '04

17 Apr '04

Filip Navara wrote: > > Hi, > > here is my proposed solution for crashes in COMCTL32 observed in > specific situations while calling the window procedure subclassing > functions. If there were removed all subclassed window procedures during > the execution of SubclassWndProc there happened a crash, because the > structure that holds the subclassing stack was freed in DefSubclassProc. Yes, that was my fault. Sorry. > Also if there were some window procedure subclassings removed during the > execution of SubclassWndProc, the stack position counting could have > gone wrong. My solution is to let the subclassing stack grow the > opposite way, so that item 0 is the most nested one. I also removed the > stacknew handling which I strongly believe is redundant now. It looks much simpler now, but I don't understand why reversing the direction of the stack should make any difference. I don't think you submitted the required patch to comctl32.h. Rob

2 4

Re: [DXDIAG2] First Implementation
by Alexandre Julliard 17 Apr '04

17 Apr '04

Raphael <fenix(a)club-internet.fr> writes: > + * @TODO: fix wine headers dependencies > + */ > +#if !defined( _MSC_VER ) || defined( __WINE__ ) > +# include "windef.h" > +# include "winbase.h" > +# include "wingdi.h" > +# include "winuser.h" > +/** GetProp is a define by user.h */ > +# undef GetProp > +/* VARIANT */ > +# include <oleauto.h> > +#endif > +/** > + * End Hack > + */ This is because on Windows many headers include windows.h and we don't want to do that in Wine. There's no reason to add #ifdefs though, it should build just fine on Windows even with the extra includes. > +#undef EXPORT_STDAPI > +#if defined( _MSC_VER ) > +# define EXPORT_STDAPI __declspec(dllexport) extern HRESULT > +#else > +# define EXPORT_STDAPI extern HRESULT > +#endif We don't need that sort of thing in Wine dlls, and it confuses winapi_check, so please don't do it. Also you forgot to include the spec file in your patch... -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: [dx104] better hardware vertex shader activation
by Alexandre Julliard 17 Apr '04

17 Apr '04

Raphael <fenix(a)club-internet.fr> writes: > Changelog: > - Use a config entry (instead of the registrry) to control the HW vertex > shader activation Actually the registry is probably a better idea, this way we don't need to move it again once we get rid of the config file. I'd suggest Sofware\Wine\d3d instead of Sofware\Wine\Wine\d3d though, this is more likely to be the correct place once the config reorganization is done. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: abnt2 keyboard patch
by Rafael Ávila de Espíndola 17 Apr '04

17 Apr '04

> That's why I said that it's an X11 bug and we can do nothing about it. > > Please resubmit the patch without that part. Attached. I will contact xfree and try to fix the rest of the problem. Thanks. > Dmitry. Rafael

2 1

Re: Visual FoxPro
by Dan Kegel 17 Apr '04

17 Apr '04

Cecil Champenois wrote: > I have heard that there is a lot of interest in moving the WINE for > Visual FoxPro forward. About a year ago, a major FoxPro developer by the > name of Whil Hentzen was telling our User Group www.ocfox.org about the > Visual FoxPro work you are doing with WINE. He also demonstrated Visual > FoxPro working on a Linux laptop. We were all very impressed by this and > anted to jump right into development but were told that the conversion > or whatever you want to call it was at least 1 to 1.5 years away. This > discouraged us a bit, so what we'd like to know is this: Where does the > WINE work in relation to VFP 6, 76 and 8 stand now? > > We would like to begin some development in Linux, but need to know where > the WINE work stands at this time and what the future looks like. Hi Cecil! I went to the VFP UG in Los Angeles that week just to meet Whil, he's a nice guy. I think what he was probably talking about when he said "1 to 1.5 years away" was that Wine had some rough edges. It still does, but they're steadily being cleaned up, and Wine is getting smoother and smoother every month. You should probably give it a try. Build it from fresh sources (it's not too hard), set up a small test app in VFP, and give it a try on Wine. If you run into problems, let us know. - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

1 0

Compilation problems in glu32/glu.c
by Luke Stras 17 Apr '04

17 Apr '04

I've recently downloaded a fresh copy out of CVS, and get the following errors while compiling: make[2]: Entering directory `/home/stras/src/wine/wine/dlls/glu32' ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./glu32.spec glu.o glu32.dll.dbg.o -o glu32.dll.so -L../../dlls -lkernel32 -lntdll -L../../libs/wine -lwine -L/usr/X11R6/lib -lSM -lICE -lXxf86dga -lXxf86vm -lXv -lXext -lX11 -lGL -lGLU -L../../libs/port -lwine_port glu.o(.text+0x765): In function `wine_gluTessBeginPolygon': /home/stras/src/wine/wine/dlls/glu32/glu.c:437: undefined reference to `gluTessBeginPolygon' glu.o(.text+0x786): In function `wine_gluTessEndPolygon': /home/stras/src/wine/wine/dlls/glu32/glu.c:447: undefined reference to `gluTessEndPolygon' glu.o(.text+0x9b2): In function `wine_gluTessBeginContour': /home/stras/src/wine/wine/dlls/glu32/glu.c:577: undefined reference to `gluTessBeginContour' glu.o(.text+0x9d6): In function `wine_gluTessEndContour': /home/stras/src/wine/wine/dlls/glu32/glu.c:587: undefined reference to `gluTessEndContour' glu.o(.text+0xa2b): In function `wine_gluTessProperty': /home/stras/src/wine/wine/dlls/glu32/glu.c:608: undefined reference to `gluTessProperty' glu.o(.text+0xa60): In function `wine_gluTessNormal': /home/stras/src/wine/wine/dlls/glu32/glu.c:618: undefined reference to `gluTessNormal' collect2: ld returned 1 exit status winegcc: gcc failed. Any ideas? Thanks. -- Luke Stras <stras(a)utias.toronto.edu> "The meek can have the Earth; the rest of us have other plans" --Henry Spencer -- Scanned by ClamAv - http://www.clamav.net

1 0

Re: compiling wine on Darwin/MacOS X 8/10
by Alexandre Julliard 17 Apr '04

17 Apr '04

emmanuel maillard <e.rsz(a)libertysurf.fr> writes: > Changelog > Fix a lstat problem on darwin I don't think you want to remove the check. What error does lstat return in that case? -- Alexandre Julliard julliard(a)winehq.org

2 2

COMCTL32 Subclassing
by Filip Navara 16 Apr '04

16 Apr '04

Hi, I have found a bug in Wine's comctl32.dll that causes crashes with subclassed windows. There can happen a situation when DefSubclassProc ends with all subclassings removed, in this case it cleans up the subclassing stack stored in a window property and frees it's memory. If DefSubclassProc was called from SubclassWndProc, there will happen crash because the subclassing stack is no longer valid. Anyone has a solution for this? - Filip --- lib/comctl32/commctrl.c 15 Apr 2004 08:29:56 -0000 1.9 +++ lib/comctl32/commctrl.c 16 Apr 2004 23:32:26 -0000 @@ -1284,9 +1284,7 @@ } stackpos = stack->stackpos; stack->stackpos = stack->stacknum; - ret = DefSubclassProc(hWnd,uMsg,wParam,lParam); - stack->stackpos = stackpos; - return ret; + return DefSubclassProc(hWnd,uMsg,wParam,lParam); }

1 0

Problem with winealsa
by Francois Gouget 16 Apr '04

16 Apr '04

I decided to run the winmm test in interactive mode with wineoss and winealsa to see if everything is ok. So first, to do that just do: cd dlls/winmm/tests WINETEST_INTERACTIVE=1 ../../../tools/runtest -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so wave.c That will most likely run it with wineoss as the sound driver, then edit ~/.wine/config so it looks like this: [WinMM] ; Uncomment the "Drivers" line matching your sound setting. ;"Drivers" = "wineoss.drv" ; default for most common configurations ;"Drivers" = "winearts.drv" ; for KDE "Drivers" = "winealsa.drv" ; for ALSA users ;"Drivers" = "winejack.drv" ; for Jack sound server ;"Drivers" = "winenas.drv" ; for NAS sound system ;"Drivers" = "wineaudioio.drv" ; for Solaris machines ;"Drivers" = "" ; to disable sound And you should get exactly the same result but with the winealsa driver. Actually, it may play a couple extra or a couple less tones depending on what Alsa's OSS emulation and Alsa-native report as their supported sound formats. Anyway, each tone should play for 1 second. This is the case when using wineoss but when using winealsa they play for only 0.5 second! Does anyone have any insight into this? While I was at it I also tested winearts and it played the tones at a rate of 1 per second as expected. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.

1 0

winapi_check broken
by Stefan Leichter 16 Apr '04

16 Apr '04

Hello, winapi_check --cross-call-unicode-ascii does not longer work for me. Looks like it loops when searching for the spec-files. Does anyone else noticed this problem? Normaly a run took less than 10 minutes for me. Today i stopped it after two hours. There was only one output line: .: searching for /\.spec$/ My system is SuSE 9.0 Bye Stefan

1 0

Re: controls/menu.c
by Dimitrie O. Paun 16 Apr '04

16 Apr '04

On Fri, 16 Apr 2004, Ge van Geldorp wrote: > This fixes the black text on white background in AbiWord menus > > Changelog: > Ge van Geldorp <gvg(a)reactos.com> > Setup menu drawing colors before calling owner draw routine Good catch Ge, this was really annoying, and maybe the most upsetting visual glitch. We still have a refresh/invalidate off-by-one bug somewhere, the dialogs leave a black margin (to the right and at the bottom). Did you see that? -- Dimi.

2 1

Re: dlls/richedit/reader.c
by Phil Krylov 16 Apr '04

16 Apr '04

Hello Ge, Friday, April 16, 2004, 3:56:41 PM, you wrote: GvG> Changelog: GvG> Ge van Geldorp <gvg(a)reactos.com> GvG> Work around problem in NSIS installers which can't handle 1 char GvG> at a time reading of RTF text. To make it fully compatible with MS richedit, the buffer size should be not 10 chars, but 4096. Although it's not documented, all versions of MS Richedit always use this value. -- Best regards, Phil mailto:phil@newstar.rinet.ru

2 1

RE: Handling dialog messages for non-template based dialogs
by Santosh Siddheshwar 16 Apr '04

16 Apr '04

Could you take a look at this fix? I would think I have resolved the other issue with SetDefButton as well. Tests with msg ran fine. Regards Santosh Siddheshwar <<patch.diff>> > -----Original Message----- > From: Dmitry Timoshkov [SMTP:dmitry@baikal.ru] > Sent: Friday, April 16, 2004 1:35 PM > To: Santosh Siddheshwar; Alexandre Julliard > Cc: Robert Shearman; wine-devel(a)winehq.org > Subject: Re: Handling dialog messages for non-template based dialogs > > "Santosh Siddheshwar" <santosh.s(a)sonata-software.com> wrote: > > > This test fails with WINE even after I create the DIALOGINFO structure > the > > first time it enters DefDlgProc. Not sure why this test should work on > > Windows. > > Since I wrote it under Windows it apparently works there. > > > Basically at the stage where you are setting DM_SETDEFID there are > > no child windows on the dialog. > > Yes, I was also confused when I saw this for the first time. > > > Then what does DM_SETDEFID and DM_GETDEFID do when there are no child > > controls on the dialog? > > Looks like it should store id in the dialog structure, and only then try > to change the look of a control. > > > My guess is implementation of DEFDLG_SetDefButton > > may need to change. > > Yes, but that's another bug, not related to your patch. Although it would > be > great if you could fix that as well, don't bother if you have no time, > I'll > fix it later, this should be a very simple patch. > > -- > Dmitry. ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

2 1

[Peter Riocreux] Re: dlls/kernel/console.c::SetConsoleCtrlHandler() cleanup/fixup
by Peter Riocreux 16 Apr '04

16 Apr '04

Sorry, mistyped the wine-patches address before ...

1 0

RE: Handling dialog messages for non-template based dialogs
by Santosh Siddheshwar 16 Apr '04

16 Apr '04

This test fails with WINE even after I create the DIALOGINFO structure the first time it enters DefDlgProc. Not sure why this test should work on Windows. Basically at the stage where you are setting DM_SETDEFID there are no child windows on the dialog. Then what does DM_SETDEFID and DM_GETDEFID do when there are no child controls on the dialog? My guess is implementation of DEFDLG_SetDefButton may need to change. Regards Santosh Siddheshwar > -----Original Message----- > From: Dmitry Timoshkov [SMTP:dmitry@baikal.ru] > Sent: Thursday, April 15, 2004 5:48 PM > To: Santosh Siddheshwar; Alexandre Julliard > Cc: Robert Shearman; wine-patches(a)winehq.com > Subject: Re: Handling dialog messages for non-template based dialogs > > "Santosh Siddheshwar" <santosh.s(a)sonata-software.com> wrote: > > > OK.One place where this could be done is WM_NCCREATE which comes before > > WM_CREATE. Other place (possibly better) where it might be possible to > do > > this is in CBTProc hook procedure. Not sure about the second option > though. > > Any thoughts? > > Attached test case shows that dialog info is initialized on the very first > DefDlgProc invocation. > > So, DefDlgProc16/A/W as the very first thing should call DIALOG_get_info > and > if it returns NULL initialize dialog structures. > > Alexandre, please apply the test as soon as the dialog initialization is > fixed. > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Add a message test for custom dialog initialization. > > -- > Dmitry. << File: msg.c.diff >> ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

2 1

Re: [Darwine] compiling wine on Darwin/MacOS X 5/10
by Pierre d'Herbemont 16 Apr '04

16 Apr '04

Emmanuel, Index: libs/wine/loader.c =================================================================== RCS file: /home/wine/wine/libs/wine/loader.c,v retrieving revision 1.16 diff -u -r1.16 loader.c --- libs/wine/loader.c 2 Jan 2004 21:08:05 -0000 1.16 +++ libs/wine/loader.c 15 Apr 2004 18:17:07 -0000 @@ -182,6 +182,9 @@ +#ifdef __APPLE__ + if ((test_only == 0x2) && (ret = wine_dlopen(path, RTLD_NOW | RTLD_GLOBAL, error, errorsize ))) break; +#endif +#ifdef __APPLE__ + if (!(ntdll = dlopen_dll( "ntdll.dll", error, error_size, 0x2, &file_exists ))) return; +#else if (!(ntdll = dlopen_dll( "ntdll.dll", error, error_size, 0, &file_exists ))) return; +#endif These tests are no longer useful on Mac OS X. It was when ntdll was built as a dylib. However the check for environ is useful. Pierre On 15 avr. 04, at 23:36, emmanuel maillard wrote: > Hi, > here come some patches to build wine on Darwin/OS X > > Changelog > Build dylib on Darwin > > emmanuel > > <libs.diff>

1 0

Re: Wine fixes
by Dimitrie O. Paun 16 Apr '04

16 Apr '04

On April 16, 2004 12:16 am, Dimitrie O. Paun wrote: > IMO should just nuke some of these useless includes. > How can we test that they are really needed? Oops, sorry folks, this message was meant for the AbiWord guys! :) -- Dimi.

1 0

Re: abnt2 keyboard patch
by Rafael Ávila de Espíndola 16 Apr '04

16 Apr '04

> I still see problems with your patch. > > 1. You are using 'keysym == 0x2C' for comma, but what happens if NumLock > is on, and you press comma on the main keyboard, not on the keypad? > Shouldn't X11 send XK_KP_xxx event in that case (something like XK_KP_Decimal)? The file /usr/include/X11/keysymdef.h has the line #define XK_KP_Separator 0xFFAC /* separator, often comma */ This appears to be appropriate. But X11 is not sending it in debian (sid) or fedora. The output from xev when, with the numlock initially off, I press comma, kp_comma, numlock, comma and kp_comma is: KeyPress event, serial 22, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69979707, (124,72), root:(364,205), state 0x0, keycode 59 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," KeyRelease event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69979799, (124,72), root:(364,205), state 0x0, keycode 59 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," KeyPress event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69980420, (124,72), root:(364,205), state 0x0, keycode 91 (keysym 0xff9f, KP_Delete), same_screen YES, XLookupString gives 0 bytes: "" KeyRelease event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69980521, (124,72), root:(364,205), state 0x0, keycode 91 (keysym 0xff9f, KP_Delete), same_screen YES, XLookupString gives 0 bytes: "" KeyPress event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69980955, (124,72), root:(364,205), state 0x0, keycode 77 (keysym 0xff7f, Num_Lock), same_screen YES, XLookupString gives 0 bytes: "" KeyRelease event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69981057, (124,72), root:(364,205), state 0x10, keycode 77 (keysym 0xff7f, Num_Lock), same_screen YES, XLookupString gives 0 bytes: "" KeyPress event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69981755, (124,72), root:(364,205), state 0x10, keycode 59 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," KeyRelease event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69981850, (124,72), root:(364,205), state 0x10, keycode 59 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," KeyPress event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69982436, (124,72), root:(364,205), state 0x10, keycode 91 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," KeyRelease event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69982535, (124,72), root:(364,205), state 0x10, keycode 91 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," > 2. Please generate unified diffs, 'using diff -u' for patches. Sorry. I am really embarrassed. An unified diff is attached. > > -- > Dmitry. Rafael

2 1

Re: dlls/kernel/console.c::SetConsoleCtrlHandler() cleanup/fixup
by Dimitrie O. Paun 16 Apr '04

16 Apr '04

On April 15, 2004 11:18 am, Peter Riocreux wrote: > * This doesn't yet matter, since these handlers are not yet called...! > + * > + * Peter Riocreux (par(a)silistix.com) 2004-04-15 > + * Added error checking and now uses SetLastError() > */ One more thing: please don't add this sort of thing, it belongs in the CVS log, not in the source code. -- Dimi.

1 0

Re: [D3D8] Add support for vertex shader (using ARB_vertex_program extension)
by Christian Costa 15 Apr '04

15 Apr '04

Maxime Bellengé wrote: >Hi Christian > >Are you looking for someone to test the patch on an NVIDIA card ? >If you tell me how to test or the game to run, I can give you a >feedback. > >a+ > >Max > > > Hi Maxime, You can try the vertexblend, vertexshader & dolphinvs demos from the DX8 SDK. You can switch between HAL to REF devices to see the difference. Thanks for testing! :-) Bye, Christian

1 0

RE: More serial access issues
by Geoffrey Hausheer 15 Apr '04

15 Apr '04

Well, after tracing the events through wineserver, I see 'serial_queue_event' gets called, serial_get_poll_events returns 'POLLOUT', async_notify gets called (but async->thread->wait is 0, so it doesn't do anything besides setting the status to STATUS_ALERTED. The secod serial_get_poll_events returns 0 (due to the status no longer being STATUS_PENDING), but this doesn't really matter as the 'register_async' call doesn't create a reply. Back in my application, __register_async does not reset u.Status (since 'ret' is 0), which means that 'finish_async' never gets called, which appears to be the only way that FILE_AsyncWriteService can be called (which actually does the write) ,and no data is written to the serial port. It all seems to operate as the code dictates, so I'm not sure what the right fix is. It would seem to me that something is not working right in __register_async. Perhaps finish_async should not be gated by 'u.Status'? Or u.Status should unconditionally be set equal to 'ret'? The second seems more likely to me, as that is the only way the WriteFile could return TRUE (in fact I see no way that WriteFile could return true in today's code, regardless of what the server does (since u.Status can only be changed from STATUS_PENDING if ret != 0 (and STATUS_SUCCESS == 0), so u.Status can never equal STATUS_SUCCESS. I am having a lot of difficulty understanding exactly what the server call is doing (I think it is checking that it is clear to write to the Serial port, though it seems to be awfully complex if that is all). Also, I don't know what the conditions are under which finish_async should be called. I changed the code to unconditionally set u.Status = ret, and WriteFile is no longer returning an error, but this didn't help (I'm never seeing FILE_AsyncWriteService get called, because call completion is disabled). So it looks like there are several points that are preventing FILE_AsyncWriteService from being called, and maybe I'm barking up the wrong tree. I can see a few possibilities: (1) some other routine is supposed to do the write, and I'm missing it, or (2) the server is supposed to do the write (perhaps via asyncy_notify?), in which case I don't see any place where the write buffer is passed to the server, or (c) the server is supposed to tell the client to do the write (again by async_notify?), in which case, I'm not seeing how that works. This code seems to run around in circles to me. .Geoff -----Original Message----- From: Geoffrey Hausheer Sent: Wednesday, April 14, 2004 2:05 PM Subject: More serial access issues Well, I broke down and pulled out the oscope and rs232 breakout box to try to figure out why my app isn't able to communicate with the device. turns out that Rein's patch is correctly deasserting DSR, however, I am not getting any data over the Tx pin. And after I checked the output of WriteFile, it is failing. GetLastError doesn't return anything useful (a value of 997 which FormatMessage() can't do anything with). But some debugging led me to determine that NtWriteFile is returning 0x103 which is STATUS_PENDING. After that I'm somewhat lost as to what is going on. Obvioulsy, 'register_new_async' is returning this status, which apparently happens when wine_server_call returns 0 or STATUS_PENDING (not sure if the second is even possible). But about here I am getting completely confused as to what we are trying to accomplish. The file is opened via: CreateFile("COM1", 0, NULL, OPEN_EXISTING, 0, NULL) so we're not in overlapped mode. SetCommTimeout is called with the COMMTIMEOUTS structure containing all 0s. All flow control is disabled using SetCommState. Before a write, we always call 'PurgeComm' and ClearCommError. In Windows, this combination results in a write always occurring when WriteFile is called, regardless of whether there is anything connected to the serial port. Wine appears to be waiting for something, and I'm not sure what. If anyone has any ideas how I might proceed, i'd be glad to hear them. Thanks, .Geoff

1 0

Compiling MFC with latest CVS checkout.
by Manjunath Sripadarao 15 Apr '04

15 Apr '04

I am trying to compile MFC with latest CVS checout, I copied the source from the windows MFC dir and also the include dir (both for MFC and the VC98 include dir). I ran winemaker --interactive . and specified the -I paths. I got a couple of makefiles. Now if I do a make I get this error. [manju@manju MSVS]$ make make[1]: Entering directory `/home/manju/MSVS/mfc/src' wineg++ -mwindows -mno-cygwin -o mfcdb.so mfcdb.res mfcdb.dbg.o -lodbc32 -lole32 -loleaut32 -lwinspool -luuid mfcdb.exe-ueIUVp.spec.c:451: error: invalid conversion from `void (*)()' to ` void*' winegcc: gcc failed. make[1]: *** [mfcdb.so] Error 2 make[1]: Leaving directory `/home/manju/MSVS/mfc/src' make: *** [mfc/src] Error 2 Any ideas/tips. Am I even following the correct procedure ? There doesn't seem to be any document detailing this process. Any tips/instructions/suggestions would be greatly appreciated. I am doing this on a fedora core 1 (with prelink fixed and stuff, wine runs well), with a 2 Ghz P4 machine. If any other info is needed please feel free. Thanks in advance, Manju

3 3

wine/tools wineinstall
by Saulius Krasuckas 15 Apr '04

15 Apr '04

> Log message: > Only create the device symlinks the first time around. <skipped /> > + # Check if dosdevices exists and create it if necessary > + if [ ! -d ~/.wine/dosdevices ] > + then > + mkdir ~/.wine/dosdevices > + ln -s /mnt/fd0 ~/.wine/dosdevices/a: > + ln -s $CROOT ~/.wine/dosdevices/c: Alexandre, what about the case when ~/.wine/dosdevices exists but is empty? PS eghm, should it be bad for wineinstall and winecfg to share common code for creating links in dosdevices/ ?

2 1

help fixing up SetConsoleCtrlHandler()
by Peter Riocreux 15 Apr '04

15 Apr '04

Having seen a lot of messages like: ----------------- fixme:console:SetConsoleCtrlHandler (0x41a8af,1) - no error checking or testing yet ----------------- lately, I thought I would actually see if I could fix it up and remove the FIXME. It is in dlls/kernel/console.c, and the MSDN reference is at <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/ba…>. I think it is obvious enough that even I, a Wine newbie could do it, except for a couple of things that, as a newbie, are not obvious to me. Please point me at docs if this is covered somewhere - it is hard getting into a new project .... 1) If I am using SetLastError, it is not obvious to me what error values I should be using there. I assume there is a generic couldnt-allocate-on-heap error, but other causes of error are specific to the function, and I cannot find any documentation. Should I just use a non-zero error number and put FIXMEs in for any number I had to invent? 2) Can I assume that Rtl{Enter,Leave}CriticalSection(), HeapFree(), ERR() and WARN() cannot fail (the latter two are presumably macros). 3) The docs say that it behaves eeeeeeever so slightly differently in ME/98/95 than in others. In this case it is simply that one of the arguments may not be NULL. Should I, either in general, or in this case in particular, detect which Windows version is being used and behave appropriately, or implement the more flexible approach and assume that people writing for the more restricted OS will not have used that case. If I shoudl detect, how does one go about this? Peter

3 6

Re: Who's who - Blowing my own horn.
by Kevin Koltzau 15 Apr '04

15 Apr '04

On Wednesday 14 April 2004 10:48 pm, Tony Lambregts wrote: > Blowing my own horn. ... > + <td width="300">Location: St. Albert, Alberta, Canada </td> > + <td>IRC Nick: tindalos</td></tr> Thats my IRC nick :)

1 0

RE: Handling dialog messages for non-template based dialogs
by Santosh Siddheshwar 15 Apr '04

15 Apr '04

Actually there is WM_GETMINMAXINFO which comes before WM_NCCREATE but I dont think we should put the DIALOGINFO initialization logic there. WM_NCCREATE should be the better option. Regards Santosh Siddheshwar > -----Original Message----- > From: Dmitry Timoshkov [SMTP:dmitry@baikal.ru] > Sent: Thursday, April 15, 2004 3:56 PM > To: Santosh Siddheshwar; Alexandre Julliard > Cc: Robert Shearman; wine-devel(a)winehq.org > Subject: Re: Handling dialog messages for non-template based dialogs > > "Santosh Siddheshwar" <santosh.s(a)sonata-software.com> wrote: > > > OK.One place where this could be done is WM_NCCREATE which comes before > > WM_CREATE. Other place (possibly better) where it might be possible to > do > > this is in CBTProc hook procedure. Not sure about the second option > though. > > Any thoughts? > > I'll add a test case for it in our message test suite. > > -- > Dmitry. ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

1 0

RE: Handling dialog messages for non-template based dialogs
by Santosh Siddheshwar 15 Apr '04

15 Apr '04

OK.One place where this could be done is WM_NCCREATE which comes before WM_CREATE. Other place (possibly better) where it might be possible to do this is in CBTProc hook procedure. Not sure about the second option though. Any thoughts? Regards Santosh Siddheshwar > -----Original Message----- > From: Alexandre Julliard [SMTP:julliard@winehq.org] > Sent: Thursday, April 15, 2004 9:43 AM > To: Santosh Siddheshwar > Cc: Dmitry Timoshkov; Robert Shearman; wine-devel(a)winehq.org > Subject: Re: Handling dialog messages for non-template based dialogs > > Santosh Siddheshwar <santosh.s(a)sonata-software.com> writes: > > > But dont you think that the structure is not really required till the > > window has been created successfully? > > Well, I don't think so, but the only way to know for sure is to write > a test program under Windows to determine the exact behavior. > > -- > Alexandre Julliard > julliard(a)winehq.org ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

2 1

Problem with bad generation of low-level keyboard events
by Lionel Ulmer 15 Apr '04

15 Apr '04

Hi all, While debugging GeneRally (a very nice game), I got some problems with DInput receiving spurious events (basically, as if key '0' was pressed). This is traced to the following problem : In windows/input.c, the function 'queue_kbd_event' stores the KBDLLHOOKSTRUCT structure on the stack and then calls 'HOOK_CallHooks' to send it. In my case, thread 000a receives the event and sends it to thread 0009. What happens is the following (the 'Hook:' lines were added by me) : 000a:trace:hook:HOOK_CallHooks calling hook in thread 0009 WH_KEYBOARD_LL code 0 wp 101 lp 4156ad6c 000a:trace:hook:HOOK_CallHooks Hook: 0x4156ad6c - 00000026 00000048 000000c1 0000b578 00000000 000a:trace:msg:send_inter_thread_message hwnd (nil) msg 80000007 ("#7") wp 101 lp 4156ad6c 000a: send_message( id=0009, type=1, flags=1, win=(nil), msg=80000007, wparam=00000101, lparam=4156ad6c, x=0, y=0, time=0000b587, info=00000000, timeout=2000, callback=(nil), data={} ) 000a: send_message() = 0 000a: set_queue_mask( wake_mask=00008040, changed_mask=00008040, skip_wait=1 ) 000a: set_queue_mask() = 0 { wake_bits=00000000, changed_bits=00000000 } 000a: select( flags=4, cookie=0x4156a578, timeout=0, handles={0x50} ) 000a: select() = PENDING 0009: get_handle_fd( handle=0xc0, access=80000000 ) 0009: get_handle_fd() = 0 { fd=33, type=1, flags=0 } (...) 0009:trace:ddraw:Main_DirectDrawSurface_Lock locked surface returning description : - DDSD_CAPS : DDSCAPS_OFFSCREENPLAIN DDSCAPS_VIDEOMEMORY (...) 000a: *wakeup* signaled=0 cookie=0x4156a578 000a: set_queue_mask( wake_mask=00008040, changed_mask=00008040, skip_wait=1 ) 000a: set_queue_mask() = 0 { wake_bits=00008000, changed_bits=00008000 } 000a: get_message_reply( cancel=1 ) 000a: get_message_reply() = TIMEOUT { result=00000000, data={} } 000a:trace:msg:retrieve_reply hwnd (nil) msg 80000007 ("#7") wp 101 lp 4156ad6c got reply 40218182 (err=258) 000a: finish_hook_chain( id=13 ) 000a: finish_hook_chain() = 0 000a:trace:key:queue_kbd_event Hook: 1) 0x4156ad6c - 00000026 00000048 000000c1 0000b578 00000000 000a: send_message( id=000a, type=7, flags=0, win=(nil), msg=00000101, wparam=00000026, lparam=c1480001, x=691, y=584, time=0000b578, info=00000000, timeout=-1, callback=(nil), data={} ) 000a: send_message() = 0 000a:trace:key:queue_kbd_event Hook: 2) 0x4156ad6c - 00000026 00000048 000000c1 0000b578 00000000 000a:trace:event:EVENT_ProcessEvent returns. (...) 0009: select( flags=12, cookie=0x4069f890, timeout=1081894976.490610 (-0.000077), handles={0x3c} ) 0009: select() = TIMEOUT 0009: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 0009: get_message() = 0 { type=1, win=(nil), msg=80000007, wparam=00000101, lparam=4156ad6c, x=0, y=0, time=0000b587, info=00000000, total=0, data={} } 0009:trace:msg:MSG_peek_message got type 1 msg 80000007 ("#7") hwnd (nil) wp 101 lp 4156ad6c 0009: start_hook_chain( id=13 ) 0009: start_hook_chain() = 0 { handle=0x10022, pid=0000, tid=0000, proc=0x40cd4c70, unicode=1, module=L"" } 0009:trace:hook:HOOK_CallHooks calling hook 0x40cd4c70 WH_KEYBOARD_LL code 0 wp 101 lp 4156ad6c module L"" 0009:trace:hook:HOOK_CallHooks Hook: 0x4156ad6c - 4156ad88 00000000 00000040 4156ad8c 4156ad88 A summary of my understanding of the problem : - in 'queue_kbd_event', the structure is put on the stack on the expectation that the 'HOOK_CallHooks' won't return with the message unsent. - as seen, because the thread which receives the message does not seem to handle any messages during quite a long time (it's actually loading the track between two races), this message sending time-outs on the sender's side. - so the function 'queue_kbd_event' ends and the stack gets corrupted. - which can be seen in my last 'Hook:' dump. If it's normal for the sending to time-out, we should replace this code and add some HeapAlloc on the sender side and some HeapFree on the receiver side each time such a structure is sent ... Which will be a bit problematic for performance, but well, I do not see any other way to correct this. Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 2

exec-shield patch take 5
by Mike McCormack 15 Apr '04

15 Apr '04

Hi, Here's the latest version of a patch I've written to allow wine to run without disabling exec-shield or prelinking. Mike Changes in version 5: * reserve the shared heap area as well as the PE load area * allow multiple reserve areas in libwine Changes in version 4: * set the WINEPEEXEPATH environment variable correctly Changes in version 3: * reserve only the area required by the PE EXE if launched from CreateProcess (else just a default slab) * pass the reserved area to wine, so wine knows about it * unmap the preloader after it is no longer used Changes in verison 2: * replace the shared object loader instead of using a bootstrap exe Version 1: * create a bootstrap exe that reserves memory before loading wine-pthread or wine-kthread Index: dlls/kernel/process.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/process.c,v retrieving revision 1.52 diff -u -r1.52 process.c --- dlls/kernel/process.c 14 Apr 2004 19:40:54 -0000 1.52 +++ dlls/kernel/process.c 15 Apr 2004 07:46:25 -0000 @@ -917,8 +917,6 @@ } found: - wine_free_pe_load_area(); /* the main binary is loaded, we don't need this anymore */ - /* build command line */ set_library_wargv( __wine_main_argv ); if (!build_command_line( __wine_main_wargv )) goto error; @@ -1060,7 +1058,8 @@ * * Build the environment of a new child process. */ -static char **build_envp( const WCHAR *envW, const WCHAR *extra_envW ) +static char **build_envp( const WCHAR *envW, const WCHAR *extra_envW, + const char *workdir, const char *unixpath ) { const WCHAR *p; char **envp; @@ -1083,7 +1082,7 @@ if (!(env = malloc( length ))) return NULL; WideCharToMultiByte( CP_UNIXCP, 0, envW, p - envW, env, length, NULL, NULL ); - count += 4; + count += 6; if ((envp = malloc( count * sizeof(*envp) ))) { @@ -1098,6 +1097,11 @@ if ((p = getenv("TMP"))) *envptr++ = alloc_env_string( "TMP=", p ); if ((p = getenv("HOME"))) *envptr++ = alloc_env_string( "HOME=", p ); if ((p = getenv("WINEPREFIX"))) *envptr++ = alloc_env_string( "WINEPREFIX=", p ); + + /* record the unix working directory */ + if (workdir) *envptr++ = alloc_env_string( "WINEWORKDIR=", workdir ); + if (workdir) *envptr++ = alloc_env_string( "WINEPEEXEPATH=", unixpath ); + /* now put the Windows environment strings */ for (p = env; *p; p += strlen(p) + 1) { @@ -1106,6 +1110,8 @@ if (is_special_env_var( p )) /* prefix it with "WINE" */ *envptr++ = alloc_env_string( "WINE", p ); else if (strncmp( p, "HOME=", 5 ) && + strncmp( p, "WINEWORKDIR=", 12 ) && + strncmp( p, "WINEPEEXEPATH=", 14 ) && strncmp( p, "WINEPREFIX=", 11 )) *envptr++ = p; } *envptr = 0; @@ -1136,7 +1142,7 @@ if (!(pid = fork())) /* child */ { char **argv = build_argv( cmdline, 0 ); - char **envp = build_envp( env, NULL ); + char **envp = build_envp( env, NULL, NULL, NULL ); close( fd[0] ); /* Reset signals that we previously set to SIG_IGN */ @@ -1171,14 +1177,8 @@ RTL_USER_PROCESS_PARAMETERS *params; UNICODE_STRING image_str, cmdline_str, desktop, title; NTSTATUS status; - WCHAR buffer[MAX_PATH]; - - if(!GetLongPathNameW( filename, buffer, MAX_PATH )) - lstrcpynW( buffer, filename, MAX_PATH ); - if(!GetFullPathNameW( buffer, MAX_PATH, buffer, NULL )) - lstrcpynW( buffer, filename, MAX_PATH ); - RtlInitUnicodeString( &image_str, buffer ); + RtlInitUnicodeString( &image_str, filename ); RtlInitUnicodeString( &cmdline_str, cmdline ); if (startup->lpDesktop) RtlInitUnicodeString( &desktop, startup->lpDesktop ); if (startup->lpTitle) RtlInitUnicodeString( &title, startup->lpTitle ); @@ -1230,6 +1230,7 @@ pid_t pid; int err; char dummy = 0; + WCHAR buffer[MAX_PATH]; if (!env) { @@ -1237,7 +1238,12 @@ extra_env = DRIVE_BuildEnv(); } - if (!(params = create_user_params( filename, cmd_line, startup ))) + if(!GetLongPathNameW( filename, buffer, MAX_PATH )) + lstrcpynW( buffer, filename, MAX_PATH ); + if(!GetFullPathNameW( buffer, MAX_PATH, buffer, NULL )) + lstrcpynW( buffer, filename, MAX_PATH ); + + if (!(params = create_user_params( buffer, cmd_line, startup ))) { if (extra_env) HeapFree( GetProcessHeap(), 0, extra_env ); return FALSE; @@ -1268,7 +1274,20 @@ if (!(pid = fork())) /* child */ { char **argv = build_argv( cmd_line, 1 ); - char **envp = build_envp( env, extra_env ); + char **envp; + char *unixpath; + + unixpath = wine_get_unix_file_name( buffer ); + + /* preseve the current directory, the preloader may forget it */ + if( !unixdir ) + { + char *dir = HeapAlloc( GetProcessHeap(), 0, MAX_PATH ); + getcwd( dir, MAX_PATH ); + unixdir = dir; + } + envp = build_envp( env, extra_env, unixdir, unixpath ); + HeapFree( GetProcessHeap(), 0, unixpath ); close( startfd[1] ); close( execfd[0] ); @@ -1280,8 +1299,6 @@ /* Reset signals that we previously set to SIG_IGN */ signal( SIGPIPE, SIG_DFL ); signal( SIGCHLD, SIG_DFL ); - - if (unixdir) chdir(unixdir); if (argv && envp) { Index: libs/wine/config.c =================================================================== RCS file: /home/wine/wine/libs/wine/config.c,v retrieving revision 1.3 diff -u -r1.3 config.c --- libs/wine/config.c 11 Nov 2003 22:21:29 -0000 1.3 +++ libs/wine/config.c 15 Apr 2004 07:46:31 -0000 @@ -243,6 +243,23 @@ return user_name; } +/* run wine binary in it's own directory, so it can find it's preloader */ +int wine_cwd_execve( const char *name, char **argv, char **envp ) +{ + char *dir, *p; + + dir = strdup( name ); + p = strrchr( dir, '/' ); + if( p ) + { + *p++ = 0; + chdir( dir ); + name = p; + } + + return execve( name, argv, envp ); +} + /* exec a wine internal binary (either the wine loader or the wine server) */ /* if name is null, default to the name of the current binary */ void wine_exec_wine_binary( const char *name, char **argv, char **envp ) @@ -257,7 +274,7 @@ argv[0] = xmalloc( sizeof(BINDIR "/") + strlen(name) ); strcpy( argv[0], BINDIR "/" ); strcat( argv[0], name ); - execve( argv[0], argv, envp ); + wine_cwd_execve( argv[0], argv, envp ); free( argv[0] ); /* now try the path of argv0 of the current binary */ @@ -266,7 +283,7 @@ argv[0] = xmalloc( strlen(argv0_path) + strlen(name) + 1 ); strcpy( argv[0], argv0_path ); strcat( argv[0], name ); - execve( argv[0], argv, envp ); + wine_cwd_execve( argv[0], argv, envp ); free( argv[0] ); } @@ -283,7 +300,7 @@ memcpy( argv[0], pos, ptr - pos ); strcpy( argv[0] + (ptr - pos), "/" ); strcat( argv[0] + (ptr - pos), name ); - execve( argv[0], argv, envp ); + wine_cwd_execve( argv[0], argv, envp ); pos = ptr; } free( argv[0] ); Index: libs/wine/port.c =================================================================== RCS file: /home/wine/wine/libs/wine/port.c,v retrieving revision 1.8 diff -u -r1.8 port.c --- libs/wine/port.c 5 Feb 2004 02:01:35 -0000 1.8 +++ libs/wine/port.c 15 Apr 2004 07:46:31 -0000 @@ -150,36 +150,63 @@ #error You must implement wine_switch_to_stack for your platform #endif +struct reserve_area +{ + char *base; + size_t size; + struct reserve_area *next; +}; -static char *pe_area; -static size_t pe_area_size; +struct reserve_area *reserve_list; /*********************************************************************** - * wine_set_pe_load_area + * wine_reserve_area * - * Define the reserved area to use for loading the main PE binary. + * Define a reserved area (for the PE binary and system heap) + * These function are not thread safe, so we assume that + * they're called before any threads are started, and all the + * reserve areas are free'd. */ -void wine_set_pe_load_area( void *base, size_t size ) +void wine_reserve_area( void *base, size_t size ) { + struct reserve_area *area; unsigned int page_mask = getpagesize() - 1; char *end = (char *)base + size; - pe_area = (char *)(((unsigned long)base + page_mask) & ~page_mask); - pe_area_size = (end - pe_area) & ~page_mask; + area = malloc( sizeof (struct reserve_area) ); + + area->base = (char *)(((unsigned long)base + page_mask) & ~page_mask); + area->size = (end - area->base) & ~page_mask; + + area->next = reserve_list; + reserve_list = area; } /*********************************************************************** - * wine_free_pe_load_area + * wine_free_area * - * Free the reserved area to use for loading the main PE binary. + * Free a reserved area. */ -void wine_free_pe_load_area(void) +int wine_free_area( char *start, size_t size ) { + struct reserve_area *area, **p; + + for( p = &reserve_list; (area = *p); p = &area->next ) + if( start >= area->base && start + size <= area->base + area->size) + break; + + if( !area ) + return 0; + + *p = area->next; + #ifdef HAVE_MMAP - if (pe_area) munmap( pe_area, pe_area_size ); + munmap( area->base, area->size ); #endif - pe_area = NULL; + + free( area ); + return 1; } @@ -296,13 +323,8 @@ flags |= MAP_PRIVATE; #endif - if (pe_area && start && - (char *)start >= pe_area && - (char *)start + size <= pe_area + pe_area_size) - { - wine_free_pe_load_area(); + if ( start && reserve_list && wine_free_area(start, size) ) flags |= MAP_FIXED; - } if (!(flags & MAP_FIXED)) { Index: libs/wine/wine.def =================================================================== RCS file: /home/wine/wine/libs/wine/wine.def,v retrieving revision 1.10 diff -u -r1.10 wine.def --- libs/wine/wine.def 5 Feb 2004 02:01:35 -0000 1.10 +++ libs/wine/wine.def 15 Apr 2004 07:46:31 -0000 @@ -64,5 +64,5 @@ wine_pthread_init_thread wine_set_fs wine_set_gs - wine_set_pe_load_area + wine_reserve_area wine_switch_to_stack Index: libs/wine/wine.map =================================================================== RCS file: /home/wine/wine/libs/wine/wine.map,v retrieving revision 1.1 diff -u -r1.1 wine.map --- libs/wine/wine.map 12 Feb 2004 22:54:00 -0000 1.1 +++ libs/wine/wine.map 15 Apr 2004 07:46:31 -0000 @@ -64,7 +64,7 @@ wine_pthread_init_thread; wine_set_fs; wine_set_gs; - wine_set_pe_load_area; + wine_reserve_area; wine_switch_to_stack; local: *; Index: loader/Makefile.in =================================================================== RCS file: /home/wine/wine/loader/Makefile.in,v retrieving revision 1.14 diff -u -r1.14 Makefile.in --- loader/Makefile.in 22 Nov 2003 00:08:26 -0000 1.14 +++ loader/Makefile.in 15 Apr 2004 07:46:31 -0000 @@ -23,20 +23,30 @@ LIBPTHREAD = @LIBPTHREAD@ LDEXECFLAGS = @LDEXECFLAGS@ -wine-glibc: glibc.o Makefile.in +WINELDEXECFLAGS = $(LDEXECFLAGS),--dynamic-linker=$(WINELDSO) + +WINELDSO=ld-winepreload.so + +$(WINELDSO): preload.o Makefile.in + $(CC) -nostartfiles -lc -static -Wl,"-Ttext=0x7ff81000" -o $@ $< + +preload.c: preload.h main.h + +wine-glibc: glibc.o Makefile.in $(WINELDSO) $(CC) -o $@ $(LDEXECFLAGS) glibc.o $(LIBWINE) $(LIBPORT) $(LIBPTHREAD) $(EXTRALIBS) $(LDFLAGS) -wine-kthread: $(KTHREAD_OBJS) Makefile.in - $(CC) -o $@ $(LDEXECFLAGS) $(KTHREAD_OBJS) $(LIBWINE) $(LIBPORT) $(EXTRALIBS) $(LDFLAGS) +wine-kthread: $(KTHREAD_OBJS) Makefile.in $(WINELDSO) + $(CC) -o $@ $(WINELDEXECFLAGS) $(KTHREAD_OBJS) $(LIBWINE) $(LIBPORT) $(EXTRALIBS) $(LDFLAGS) -wine-pthread: $(PTHREAD_OBJS) Makefile.in - $(CC) -o $@ $(LDEXECFLAGS) $(PTHREAD_OBJS) $(LIBWINE) $(LIBPORT) $(LIBPTHREAD) $(EXTRALIBS) $(LDFLAGS) +wine-pthread: $(PTHREAD_OBJS) Makefile.in $(WINELDSO) + $(CC) -o $@ $(WINELDEXECFLAGS) $(PTHREAD_OBJS) $(LIBWINE) $(LIBPORT) $(LIBPTHREAD) $(EXTRALIBS) $(LDFLAGS) $(MODULE): $(MAIN_BINARY) $(RM) $(MODULE) && $(LN_S) $(MAIN_BINARY) $(MODULE) install:: $(WINE_BINARIES) $(MKINSTALLDIRS) $(bindir) + $(INSTALL_PROGRAM) $(WINELDSO) $(bindir); \ for f in $(WINE_BINARIES); do \ if [ "$(MAIN_BINARY)" = "$$f" ]; \ then $(INSTALL_PROGRAM) $$f $(bindir)/$(MODULE); \ @@ -48,6 +58,6 @@ $(RM) $(WINE_BINARIES:%=$(bindir)/%) $(bindir)/$(MODULE) clean:: - $(RM) $(WINE_BINARIES) $(MODULE) + $(RM) $(WINE_BINARIES) $(MODULE) $(WINELDSO) ### Dependencies: Index: loader/glibc.c =================================================================== RCS file: /home/wine/wine/loader/glibc.c,v retrieving revision 1.3 diff -u -r1.3 glibc.c --- loader/glibc.c 20 Feb 2004 20:19:23 -0000 1.3 +++ loader/glibc.c 15 Apr 2004 07:46:31 -0000 @@ -75,6 +75,17 @@ { const char *loader = getenv( "WINELOADER" ); const char *threads = get_threading(); + char cwd[MAX_PATH], *cwd_var; + + if( !getcwd( cwd, sizeof cwd ) ) + { + fprintf( stderr, "wine: could get current directory\n" ); + exit(1); + } + cwd_var = xmalloc( sizeof("WINEWORKDIR=") + strlen(cwd) ); + strcpy( cwd_var, "WINEWORKDIR=" ); + strcat( cwd_var, cwd ); + putenv( cwd_var ); if (loader) { @@ -86,6 +97,9 @@ new_name = xmalloc( (path - loader) + strlen(threads) + 1 ); memcpy( new_name, loader, path - loader ); + new_name[ path - loader ] = 0; + if( new_name[0] ) + chdir( new_name ); strcpy( new_name + (path - loader), threads ); /* update WINELOADER with the new name */ Index: loader/main.c =================================================================== RCS file: /home/wine/wine/loader/main.c,v retrieving revision 1.90 diff -u -r1.90 main.c --- loader/main.c 20 Jan 2004 00:28:01 -0000 1.90 +++ loader/main.c 15 Apr 2004 07:46:31 -0000 @@ -20,19 +20,54 @@ #include <stdio.h> #include <stdlib.h> +#include <unistd.h> +#include <sys/mman.h> #include "wine/library.h" +#include "main.h" + +extern void wine_reserve_area( void *base, size_t size ); + +/* this variable is set by the wine-specific shared object loader */ +struct wine_preload_info *wine_preload_vars; + /********************************************************************** * main */ int main( int argc, char *argv[] ) { - char error[1024]; + char error[1024], *dir; + if( wine_preload_vars ) + { #if 0 - static char pe_load[256*1024*1024] __attribute__((aligned(4096))); - wine_set_pe_load_area( pe_load, sizeof(pe_load) ); + printf("vars(*%p) = %p -> (%p, %08x) (%p, %08x) (%p, %08x)\n", + &wine_preload_vars, wine_preload_vars, + wine_preload_vars->pe_address, + wine_preload_vars->pe_size, + wine_preload_vars->heap_address, + wine_preload_vars->heap_size, + wine_preload_vars->preload_base, + wine_preload_vars->preload_size ); #endif + + /* let wine know which area was mapped for the PE EXE */ + wine_reserve_area( wine_preload_vars->pe_address, + wine_preload_vars->pe_size); + + /* let wine know which area was mapped for the system heap */ + wine_reserve_area( wine_preload_vars->heap_address, + wine_preload_vars->heap_size); + + /* unmap the preloader itself */ + munmap( wine_preload_vars->preload_base, + wine_preload_vars->preload_size ); + wine_preload_vars = NULL; + } + + dir = getenv( "WINEWORKDIR" ); + if( dir ) + chdir( dir ); wine_init( argc, argv, error, sizeof(error) ); fprintf( stderr, "wine: failed to initialize: %s\n", error ); --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ loader/main.h 2004-04-15 17:29:17.000000000 +0900 @@ -0,0 +1,10 @@ + +struct wine_preload_info +{ + void *pe_address; + size_t pe_size; + void *heap_address; + size_t heap_size; + void *preload_base; + size_t preload_size; +}; --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ loader/preload.h 2004-04-15 17:29:17.000000000 +0900 @@ -0,0 +1,51 @@ +/* + mini loader for ld.so - x86 Linux 2.4.x+ kernels only + + Copyright 2004 Mike McCormack for Codeweavers + + Copyright (C) 1995,96,97,98,99,2000,2001,2002 Free Software Foundation, Inc. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + 02111-1307 USA. + */ + +#define LDSO_NAME "/lib/ld-linux.so.2" + +/* ELF definitions */ +#define ELF_PREFERRED_ADDRESS(loader, maplength, mapstartpref) (mapstartpref) +#define ELF_FIXED_ADDRESS(loader, mapstart) ((void) 0) + +#define __ELF_NATIVE_CLASS 32 +#define MAP_BASE_ADDR(l) 0 +#define MAP_COPY MAP_PRIVATE +#define ANONFD -1 + +#define ElfW(type) _ElfW (Elf, __ELF_NATIVE_CLASS, type) +#define _ElfW(e,w,t) _ElfW_1 (e, w, _##t) +#define _ElfW_1(e,w,t) e##w##t + +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <unistd.h> +#include <sys/mman.h> +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> + +#define GL(x) x + +extern unsigned int GL(dl_pagesize); + --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ loader/preload.c 2004-04-15 17:29:17.000000000 +0900 @@ -0,0 +1,749 @@ +/* + mini loader for ld.so - x86 Linux 2.4.x+ kernels only + + Copyright 2004 Mike McCormack for Codeweavers + + Copyright (C) 1995,96,97,98,99,2000,2001,2002 Free Software Foundation, Inc. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + 02111-1307 USA. + */ + +/* + * Design notes + * + * The goal of this program is to be a workaround for exec-shield, as used + * by the Linux kernel distributed with Fedora Core and other distros. + * + * To do this, we implement our own shared object loader that reserves memory + * that is important to Wine, and then loads the the standard shared object + * loader (ELF interpreter), usually ld-linux.so.2 + * + * This program will be invoked by linking it as the shared object loader + * using the link time flags --shared-loader=ld-winepreload.so . Since we + * are not using an absolute path, an executable using this shared object + * loader must be invoked from the directory that contains this loader. + * + * We will try to set up the stack an memory area so that the program that + * loads after us (eg. the wine binary) never knows we were here, except that + * areas of memory it needs are already magically reserved. + * + * The following memory areas are important to Wine: + * 0x00000000 - the DOS area + * 0x00400000 - the standard Win32 load address + * 0x65430000 - the shared heap + * + * If this program is used as the shared object loader. the only difference + * that the loaded programs should see is that this loader will be mapped + * into memory when it starts. + * + * Limitations: + * * using a non-absolution path for the shared object loader is not standard + */ + +/* + * References (things I consulted to understand how ELF loading works): + * + * glibc 2.3.2 elf/dl-load.c + * http://www.gnu.org/directory/glibc.html + * + * Linux 2.6.4 fs/binfmt_elf.c + * ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.4.tar.bz2 + * + * Userland exec, by <grugq(a)hcunix.net> + * http://cert.uni-stuttgart.de/archive/bugtraq/2004/01/msg00002.html + * + * The ELF specification: + * http://www.linuxbase.org/spec/booksets/LSB-Embedded/LSB-Embedded/book387.ht… + */ + +#include "preload.h" +#include "main.h" +#include <elf.h> + +/* the following headers are needed to get the definition for IMAGE_NT_HEADERS */ +#include <stdarg.h> +#include "windef.h" +#include "winbase.h" + +/* debugging */ +#undef DUMP_SEGMENTS +#undef DUMP_ARG +#undef DUMP_AUX_INFO +#undef DUMP_SYMS +#undef DUMP_PERESERVE + +/* older systems may not define these */ +#ifndef PT_TLS +#define PT_TLS 7 +#endif +#ifndef PT_GNU_EH_FRAME +#define PT_GNU_EH_FRAME 0x6474e550 +#endif +#ifndef PT_GNU_STACK +#define PT_GNU_STACK 0x6474e551 +#endif +#ifndef PT_GNU_RELRO +#define PT_GNU_RELRO 0x6474e552 +#endif + +unsigned int GL(dl_pagesize) = 0x0000; +extern const unsigned char _end[]; + +struct link_map { + ElfW(Addr) l_addr; + ElfW(Dyn) *l_ld; + const ElfW(Phdr) *l_phdr; + ElfW(Addr) l_entry; + ElfW(Half) l_ldnum; + ElfW(Half) l_phnum; + ElfW(Addr) l_map_start, l_map_end; +}; + +/* + * wld_printf - just the basics + * + * %x prints a hex number + * %s prints a string + */ +void wld_sprintf(char *str, char *fmt, int *args ) +{ + char *p = fmt; + + while( *p ) + { + if( *p == '%' ) + { + p++; + if( *p == 'x' ) + { + int ch, i, x = *++args; + for(i=7; i>=0; i--) + { + ch = (x>>(i*4))&0xf; + ch += '0'; + if(ch>'9') + ch+=('A'-10-'0'); + *str++ = ch; + } + } + else if( *p == 's' ) + { + char *s = (char*)*++args; + while(*s) + *str++ = *s++; + } + else if( *p == 0 ) + break; + p++; + } + *str++ = *p++; + } + *str = 0; +} + +int wld_strlen(char *str) +{ + int n = 0; + while( str[n] ) + n++; + return n; +} + +void wld_printf(char *fmt, ... ) +{ + char buffer[100]; + int n; + + buffer[0]=0; + wld_sprintf(buffer, fmt, (int*)&fmt ); + n = wld_strlen( buffer ); + write(2, buffer, n); +} + +void wld_strncpy(char *dest, char *src, int count ) +{ + while( (*dest++ = *src++) && --count ) + ; + *dest = 0; +} + +void wld_memset( unsigned char *buf, int val, size_t len ) +{ + while( len-- ) + *buf++=val; +} + +#ifdef DUMP_AUX_INFO +/* + * Dump interesting bits of the ELF auxv_t structure that is passed + * as the 4th parameter to the _start function + */ +static void wld_dump_auxilary( ElfW(auxv_t) *av ) +{ + for ( ; av->a_type != AT_NULL; av++) + switch (av->a_type) + { + case AT_PAGESZ: + wld_printf("AT_PAGESZ = %x\n",av->a_un.a_val); + break; + case AT_PHDR: + wld_printf("AT_PHDR = %x\n",av->a_un.a_ptr); + break; + case AT_PHNUM: + wld_printf("AT_PHNUM = %x\n",av->a_un.a_val); + break; + case AT_ENTRY: + wld_printf("AT_ENTRY = %x\n",av->a_un.a_val); + break; + case AT_BASE: + wld_printf("AT_BASE = %x\n",av->a_un.a_val); + break; + } +} +#endif + +/* + * wld_set_auxilary + * + * Set a field of the auxillary structure + */ +void wld_set_auxilary( ElfW(auxv_t) *av, int type, long int val ) +{ + for ( ; av->a_type != AT_NULL; av++) + if( av->a_type == type ) + av->a_un.a_val = val; +} + +/* + * wld_get_auxilary + * + * Get a field of the auxillary structure + */ +int wld_get_auxilary( ElfW(auxv_t) *av, int type, int *val ) +{ + for ( ; av->a_type != AT_NULL; av++) + if( av->a_type == type ) + { + *val = av->a_un.a_val; + return 1; + } + return 0; +} + +/* + * wld_map_so + * + * modelled after _dl_map_object_from_fd() from glibc-2.3.1/elf/dl-load.c + * + * This function maps the segments from an ELF object, and optionally + * stores information about the mapping into the auxv_t structure. + */ +void* wld_map_so( int fd, void* buf, size_t buflen, struct link_map *l) +{ + ElfW(Ehdr) *header = buf; + ElfW(Phdr) *phdr, *ph; + /* Scan the program header table, collecting its load commands. */ + struct loadcmd + { + ElfW(Addr) mapstart, mapend, dataend, allocend; + off_t mapoff; + int prot; + } loadcmds[header->e_phnum], *c; + size_t nloadcmds = 0, maplength; + + header = buf; + phdr = (void*) (((unsigned char*)buf) + header->e_phoff); + + if( header->e_ident[0] != 0x7f && + header->e_ident[0] != 'E' && + header->e_ident[0] != 'L' && + header->e_ident[0] != 'F' ) + { + wld_printf("Not an ELF binary... don't know how to load it\n"); + return NULL; + } + + if( header->e_machine != EM_386 ) + { + wld_printf("Not an i386 ELF binary... don't know how to load it\n"); + return NULL; + } + + maplength = header->e_phnum * sizeof (ElfW(Phdr)); + if (header->e_phoff + maplength > (size_t) buflen) + { + wld_printf("oops... not enough space for ELF headers\n"); + exit(1); + } + + l->l_ld = 0; + l->l_addr = 0; + l->l_phnum = header->e_phnum; + l->l_entry = header->e_entry; + + for (ph = phdr; ph < &phdr[l->l_phnum]; ++ph) + { + +#ifdef DUMP_SEGMENTS + wld_printf( "ph = %x\n", ph ); + wld_printf( " p_type = %x\n", ph->p_type ); + wld_printf( " p_flags = %x\n", ph->p_flags ); + wld_printf( " p_offset = %x\n", ph->p_offset ); + wld_printf( " p_vaddr = %x\n", ph->p_vaddr ); + wld_printf( " p_paddr = %x\n", ph->p_paddr ); + wld_printf( " p_filesz = %x\n", ph->p_filesz ); + wld_printf( " p_memsz = %x\n", ph->p_memsz ); + wld_printf( " p_align = %x\n", ph->p_align ); +#endif + + switch (ph->p_type) + { + /* These entries tell us where to find things once the file's + segments are mapped in. We record the addresses it says + verbatim, and later correct for the run-time load address. */ + case PT_DYNAMIC: + l->l_ld = (void *) ph->p_vaddr; + l->l_ldnum = ph->p_memsz / sizeof (Elf32_Dyn); + break; + + case PT_PHDR: + l->l_phdr = (void *) ph->p_vaddr; + break; + + case PT_TLS: + /* + * We don't need to set anything up because we're + * emulating the kernel, not ld-linux.so.2 + * The ELF loader will set up the TLS data itself. + */ + break; + + case PT_LOAD: + { + if ((ph->p_align & (GL(dl_pagesize) - 1)) != 0) + { + wld_printf("ELF load command alignment not page-aligned"); + return NULL; + } + if (((ph->p_vaddr - ph->p_offset) & (ph->p_align - 1)) != 0) + { + wld_printf("ELF load command address/offset not properly aligned"); + return NULL; + } + + c = &loadcmds[nloadcmds++]; + c->mapstart = ph->p_vaddr & ~(ph->p_align - 1); + c->mapend = ((ph->p_vaddr + ph->p_filesz + GL(dl_pagesize) - 1) + & ~(GL(dl_pagesize) - 1)); + c->dataend = ph->p_vaddr + ph->p_filesz; + c->allocend = ph->p_vaddr + ph->p_memsz; + c->mapoff = ph->p_offset & ~(ph->p_align - 1); + + c->prot = 0; + if (ph->p_flags & PF_R) + c->prot |= PROT_READ; + if (ph->p_flags & PF_W) + c->prot |= PROT_WRITE; + if (ph->p_flags & PF_X) + c->prot |= PROT_EXEC; + } + break; + + case PT_INTERP: + break; + + case PT_SHLIB: + case PT_NOTE: + case PT_GNU_EH_FRAME: + case 0x6474e551: /* FIXME: what is this? */ + break; + + default: + wld_printf("warning: unknown header type %x\n", ph->p_type); + break; + } + } + + /* Now process the load commands and map segments into memory. */ + c = loadcmds; + + /* Length of the sections to be loaded. */ + maplength = loadcmds[nloadcmds - 1].allocend - c->mapstart; + + if( header->e_type == ET_DYN ) + { + ElfW(Addr) mappref; + mappref = (ELF_PREFERRED_ADDRESS (loader, maplength, c->mapstart) + - MAP_BASE_ADDR (l)); + + /* Remember which part of the address space this object uses. */ + l->l_map_start = (ElfW(Addr)) mmap ((void *) mappref, maplength, + c->prot, MAP_COPY | MAP_FILE, + fd, c->mapoff); + /* wld_printf("set : offset = %x\n", c->mapoff); */ + /* wld_printf("l->l_map_start = %x\n", l->l_map_start); */ + + l->l_map_end = l->l_map_start + maplength; + l->l_addr = l->l_map_start - c->mapstart; + + mprotect ((caddr_t) (l->l_addr + c->mapend), + loadcmds[nloadcmds - 1].allocend - c->mapend, + PROT_NONE); + goto postmap; + } + else + { + ELF_FIXED_ADDRESS (loader, c->mapstart); + } + + /* Remember which part of the address space this object uses. */ + l->l_map_start = c->mapstart + l->l_addr; + l->l_map_end = l->l_map_start + maplength; + + while (c < &loadcmds[nloadcmds]) + { + if (c->mapend > c->mapstart) + /* Map the segment contents from the file. */ + mmap ((void *) (l->l_addr + c->mapstart), + c->mapend - c->mapstart, c->prot, + MAP_FIXED | MAP_COPY | MAP_FILE, fd, c->mapoff); + + postmap: + if (l->l_phdr == 0 + && (ElfW(Off)) c->mapoff <= header->e_phoff + && ((size_t) (c->mapend - c->mapstart + c->mapoff) + >= header->e_phoff + header->e_phnum * sizeof (ElfW(Phdr)))) + /* Found the program header in this segment. */ + l->l_phdr = (void *) (c->mapstart + header->e_phoff - c->mapoff); + + if (c->allocend > c->dataend) + { + /* Extra zero pages should appear at the end of this segment, + after the data mapped from the file. */ + ElfW(Addr) zero, zeroend, zeropage; + + zero = l->l_addr + c->dataend; + zeroend = l->l_addr + c->allocend; + zeropage = ((zero + GL(dl_pagesize) - 1) + & ~(GL(dl_pagesize) - 1)); + + /* + * This is different to the dl-load load... + * ld-linux.so.2 relies on the whole page being zero'ed + */ + zeroend = (zeroend +GL(dl_pagesize) - 1) & ~(GL(dl_pagesize) - 1); + + if (zeroend < zeropage) + { + /* All the extra data is in the last page of the segment. + We can just zero it. */ + zeropage = zeroend; + } + + if (zeropage > zero) + { + /* Zero the final part of the last page of the segment. */ + if ((c->prot & PROT_WRITE) == 0) + { + /* Dag nab it. */ + mprotect ((caddr_t) (zero & ~(GL(dl_pagesize) - 1)), + GL(dl_pagesize), + c->prot|PROT_WRITE); + } + memset ((void *) zero, '\0', zeropage - zero); + if ((c->prot & PROT_WRITE) == 0) + mprotect ((caddr_t) (zero & ~(GL(dl_pagesize) - 1)), + GL(dl_pagesize), c->prot); + } + + if (zeroend > zeropage) + { + /* Map the remaining zero pages in from the zero fill FD. */ + caddr_t mapat; + mapat = mmap ((caddr_t) zeropage, zeroend - zeropage, + c->prot, MAP_ANON|MAP_PRIVATE|MAP_FIXED, + ANONFD, 0); + } + } + + ++c; + } + + if (l->l_phdr == NULL) + { + wld_printf("no program header\n"); + exit(1); + } + + (ElfW(Addr)) l->l_phdr += l->l_addr; + (ElfW(Addr)) l->l_entry += l->l_addr; + + return (void*)l->l_entry; +} + +#define ROUND_SIZE(addr,size) \ + (((int)(size) + ((int)(addr) & page_mask) + page_mask) & ~page_mask) + +/* + * wld_reserve_wine_memory + * + * This is the reason we are here. + * We want to reserve address space so that the kernel doesn't + * map stuff there. We do this by getting in first before + * anything else is mapped (except this program) and reserve + * the memory we want. + */ +void wld_reserve_wine_memory( char *pe_file, void **base, size_t *size ) +{ + IMAGE_DOS_HEADER dos; + IMAGE_NT_HEADERS nt; + int unix_fd, page_mask = GL(dl_pagesize) - 1; + + if( !pe_file ) + return; + + unix_fd = open( pe_file, O_RDONLY, 0); + if( unix_fd < 0 ) + return; + + /* + * The following code is borrowed from + * get_image_params() in wine/server/mapping.c + */ + if (read( unix_fd, &dos, sizeof(dos) ) != sizeof(dos)) goto error; + if (dos.e_magic != IMAGE_DOS_SIGNATURE) goto error; + if (lseek( unix_fd, dos.e_lfanew, SEEK_SET ) == -1) goto error; + + if (read( unix_fd, &nt.Signature, sizeof(nt.Signature) ) != sizeof(nt.Signature)) goto error; + if (nt.Signature != IMAGE_NT_SIGNATURE) goto error; + if (read( unix_fd, &nt.FileHeader, sizeof(nt.FileHeader) ) != sizeof(nt.FileHeader)) goto error; + /* zero out Optional header in the case it's not present or partial */ + memset(&nt.OptionalHeader, 0, sizeof(nt.OptionalHeader)); + if (read( unix_fd, &nt.OptionalHeader, nt.FileHeader.SizeOfOptionalHeader) != nt.FileHeader.SizeOfOptionalHeader) goto error; + + *size = ROUND_SIZE( 0, nt.OptionalHeader.SizeOfImage ); + *base = (void *)nt.OptionalHeader.ImageBase; + +#ifdef DUMP_PERESERVE + wld_printf( "file %s\n", pe_file ); + wld_printf( "parsed PE image... base %x size %x\n", *base, *size ); +#endif + +error: + close( unix_fd ); +} + +/* + * Find a symbol in the symbol table of the executable loaded + */ +void *wld_find_symbol( const ElfW(Phdr) *phdr, int num, char *var ) +{ + const ElfW(Dyn) *dyn = NULL; + void *ptr = NULL; + const ElfW(Phdr) *ph; + const ElfW(Sym) *symtab = NULL; + const char *strings = NULL; + + /* check the values */ +#ifdef DUMP_SYMS + wld_printf("%x %x\n", phdr, num ); +#endif + if( ( phdr == NULL ) || ( num == 0 ) ) + { + wld_printf("could not find PT_DYNAMIC header entry\n"); + return NULL; + } + + /* parse the (already loaded) ELF executable's header */ + for (ph = phdr; ph < &phdr[num]; ++ph) + { + if( PT_DYNAMIC == ph->p_type ) + { + dyn = (void *) ph->p_vaddr; + num = ph->p_memsz / sizeof (Elf32_Dyn); + break; + } + } + if( !dyn ) + { + wld_printf("No PT_DYNAMIC section\n"); + return ptr; + } + + while( dyn->d_tag ) + { + if( dyn->d_tag == DT_STRTAB ) + strings = (const char*) dyn->d_un.d_ptr; + if( dyn->d_tag == DT_SYMTAB ) + symtab = (const ElfW(Sym) *)dyn->d_un.d_ptr; +#ifdef DUMP_SYMS + wld_printf("%x %x\n", dyn->d_tag, dyn->d_un.d_ptr ); +#endif + dyn++; + } + + if( (!symtab) || (!strings) ) + { + wld_printf("No symbol table found\n"); + return ptr; + } + + /* FIXME: this crashes if it doesn't find the symbol we want */ + do + { + if( ( ELF32_ST_BIND(symtab->st_info) == STT_OBJECT ) && + ( 0 == strcmp( strings+symtab->st_name, var ) ) ) + { + ptr = (void*)symtab->st_value; + break; + } + symtab++; + } + while( symtab->st_name ); + +#ifdef DUMP_SYMS + wld_printf("Found %s -> %x\n", strings+symtab->st_name, symtab->st_value ); +#endif + + return ptr; +} + +/* + * wld_start + * + * Repeat the actions the kernel would do when loading a dynamically linked .so + * Load the ELF interperter ld-linux.so and then binary itself. + * + * Note, we assume that the binary is a dynamically linked ELF shared object + * and that ld-linux.so is its ELF interpreter. + */ +void* wld_start( int argc ) +{ + int fd, phnum = 0; + unsigned char buf[0x800]; + void *start; + char **argv = (char**) &argc, **p, *pe_file = NULL; + struct link_map map; + ElfW(auxv_t)* av; + ElfW(Phdr) *elf_phdr = NULL; + struct wine_preload_info **wine_preload_vars; + static struct wine_preload_info vars; + + memset( &map, 0, sizeof map ); + + /* skip over the parameters */ + p = ++argv; +#ifdef DUMP_ARG + { + int i; + for( i = 0; i<argc; i++ ) + wld_printf("argv[%x] = %s\n", i, *p++); + if(*p++) + wld_printf("argv[argc] not NULL!!\n"); + } +#else + p+=(argc+1); +#endif + + /* skip over the environment, find the name of the PE file */ + while( *p ) + { + const char pefile[] = "WINEPEEXEPATH="; + if( 0 == memcmp( pefile, *p, sizeof pefile - 1 ) ) + pe_file = (*p) + sizeof pefile - 1 ; + p++; + } + + av = (ElfW(auxv_t)*) (p+1); + wld_get_auxilary( av, AT_PAGESZ, &dl_pagesize ); +#ifdef DUMP_AUX_INFO + wld_dump_auxilary( av ); +#endif + + /* reserve memory that Wine needs */ + vars.pe_size = 0x01000000; + vars.pe_address = (void*)0x00400000; + wld_reserve_wine_memory( pe_file, &vars.pe_address, &vars.pe_size ); + mmap( vars.pe_address, vars.pe_size, PROT_NONE, + MAP_FIXED|MAP_PRIVATE|MAP_ANON, -1, 0); + + /* reserve the memory that wine needs for the global heap */ + vars.heap_size = 0x400000; + vars.heap_address = (void*)0x65430000; + mmap( vars.heap_address, vars.heap_size, PROT_NONE, + MAP_FIXED|MAP_PRIVATE|MAP_ANON, -1, 0); + + /* load the original dynamic loader itself */ + fd = open( LDSO_NAME, O_RDONLY, 0); + if( fd < 0 ) + { + wld_printf( "error: fd = %x\n", fd); + exit(1); + } + read( fd, buf, sizeof buf ); + start = wld_map_so( fd, buf, sizeof buf, &map ); + if( !start ) + exit(0); + close( fd ); + + /* + * Pass information to the wine loader in a static variable + * so it doesn't get destroyed after we leave this stack frame + */ + wld_get_auxilary( av, AT_PHDR, (int*)&elf_phdr ); + wld_get_auxilary( av, AT_PHNUM, (int*)&phnum ); + wine_preload_vars = wld_find_symbol( elf_phdr, phnum, "wine_preload_vars" ); + if( wine_preload_vars ) + { + unsigned char *base = (void*)0x7ff81000; /* FIXME - define properly */ + vars.preload_base = (void*) base; + vars.preload_size = (size_t) (_end - base); + *wine_preload_vars = &vars; + } + + wld_set_auxilary( av, AT_BASE, map.l_addr ); + +#ifdef DUMP_AUX_INFO + wld_printf("New auxillary info:\n"); + wld_dump_auxilary( av ); + wld_printf("jumping to %x\n", start); +#endif + + return start; +} + +/* + * The _start function is the entry and exit point of this program + * + * It calls wld_start, passing a pointer to the args it receives + * then jumps to the address wld_start returns after removing the + * first argv[] value, and decrementing argc + */ +void _start(void); +__asm ( + ".align 4\n" + "\t.global _start\n" + "\t.type _start,@function\n" +"_start:\n" + "\tcall wld_start\n" + "\tpush %eax\n" + "\txor %eax,%eax\n" + "\txor %ebx,%ebx\n" + "\txor %ecx,%ecx\n" + "\txor %edx,%edx\n" + "\tret\n" +); +

1 0

Re: winegcc: use CC to compile the .spec.c file
by Alexandre Julliard 15 Apr '04

15 Apr '04

"Dimitrie O. Paun" <dimi(a)intelliware.ca> writes: > ChangeLog > Dimitrie O. Paun <dpaun(a)rogers.com> > Always use CC to compile the .spec.c file. Doesn't compile_to_object() do this already? -- Alexandre Julliard julliard(a)winehq.org

3 2

Re: Re: statvfs and cdrom problem
by Christian Costa 15 Apr '04

15 Apr '04

> Message du 15/04/04 00:35 > De : Alexandre Julliard > A : Christian Costa > Copie à : wined > Objet : Re: statvfs and cdrom problem > Christian Costa writes: > > > Yes, this works fine. Thanks. :-) > > When do you plan to rewrite GetFreeDiskSpace? > > In a few days I guess. There are still some missing features in > NtCreateFile that need to be done first. > > -- > Alexandre Julliard > julliard(a)winehq.org > Ok! Fine! :-) I have a small fix for the lpSectorsPerCluster param which should always contain 1 for CDROM. I will send a patch after your rewrite unless you fix it first. :-) Bye, Christian

1 0

RE: Handling dialog messages for non-template based dialogs
by Santosh Siddheshwar 15 Apr '04

15 Apr '04

Hi, But dont you think that the structure is not really required till the window has been created successfully? Regards Santosh Siddheshwar > -----Original Message----- > From: Alexandre Julliard [SMTP:julliard@winehq.org] > Sent: Thursday, April 15, 2004 9:00 AM > To: Dmitry Timoshkov > Cc: Santosh Siddheshwar; Robert Shearman; wine-devel(a)winehq.org > Subject: Re: Handling dialog messages for non-template based dialogs > > "Dmitry Timoshkov" <dmitry(a)baikal.ru> writes: > > > Yes, if Alexandre has no objections. Be patient, that may take some > time. > > Actually, I do have an objection... I think you should be allocating > the structure as soon as it is needed, WM_CREATE is not the first > message that the window will receive. > > -- > Alexandre Julliard > julliard(a)winehq.org ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

2 1

RE: Handling dialog messages for non-template based dialogs
by Santosh Siddheshwar 15 Apr '04

15 Apr '04

Hi, So can I expect this to be checked into cvs soon? Regards Santosh Siddheshwar > -----Original Message----- > From: Dmitry Timoshkov [SMTP:dmitry@baikal.ru] > Sent: Wednesday, April 14, 2004 5:22 PM > To: Santosh Siddheshwar; Robert Shearman > Cc: wine-devel(a)winehq.org > Subject: Re: Handling dialog messages for non-template based dialogs > > "Santosh Siddheshwar" <santosh.s(a)sonata-software.com> wrote: > > > Thanks for the feedback. Excellent catches! Hope my next mail to > > wine-patches gets through! > > Your new patch looks good for me. Thanks for doing this work! > > -- > Dmitry. ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

3 2

Re: abnt2 keyboard patch
by Dmitry Timoshkov 15 Apr '04

15 Apr '04

"Rafael аvila de EspМndola" <rafael.espindola(a)ic.unicamp.br> wrote: > I have tested the patch with a abnt2 and a us-int keyboard. Both work > correctly. > > Dmitry: Do you think that the "magic numbers" are reasonably explained? What I > have done is basically to treat the comma similarilly to the decimal period. > The numbers are different from the first patch because in the first one I > haven't fixed the main_key_scan_abnt_qwerty and main_key_vkey_abnt_qwerty > tables. I still see problems with your patch. 1. You are using 'keysym == 0x2C' for comma, but what happens if NumLock is on, and you press comma on the main keyboard, not on the keypad? Shouldn't X11 send XK_KP_xxx event in that case (something like XK_KP_Decimal)? 2. Please generate unified diffs, 'using diff -u' for patches. -- Dmitry.

1 0

dbghelp: cross-compile
by Kevin Koltzau 15 Apr '04

15 Apr '04

I decided to try cross compiling all of wine using mingw..hit a couple problems in dbghelp This fixes a few of them, it still doesn't compile (primarily because of a missing regex.h at the moment) but it does get farther I'm not sure if these fixes are quite right..I don't fully understand this code Changelog Fix a few compile errors when cross compiling

1 0

Re: MAPI32 - headers
by Alexandre Julliard 15 Apr '04

15 Apr '04

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > -#ifndef MAPICODE_H > -#define MAPICODE_H > +#ifndef __WINE_MAPICODE_H > +#define __WINE_MAPICODE_H It's better to keep the same defines as Windows, especially since in that case they are used from other headers. > -#define MAKE_MAPI_SCODE(sev,fac,code) \ > - ( (((ULONG)(sev)<<31) | ((ULONG)(fac)<<16) | ((ULONG)(code))) ) MAKE_MAPI_SCODE and the other macros are in the Windows header so we need them, you can't remove them. > +#ifndef __FLAGS > +#define __FLAGS > +typedef unsigned long FLAGS; > +#endif There is no such #ifdef in the Windows header. If there are conflicting typedefs in the Windows headers then we want conflicts in the Wine headers too, otherwise we won't be able to build the Wine code against the Windows headers. -- Alexandre Julliard julliard(a)winehq.org

1 0

Bug 560 "Integrate" AppDB and bugzilla
by Tony Lambregts 15 Apr '04

15 Apr '04

This is an update for bug 560 http://bugs.winehq.org/show_bug.cgi?id=560 I have gone through each and every bug in Bugzilla (yes all 2174 of them) and linked the ones that I could find an AppDB entry for. That translates into 756 bugs. Some of these bugs applied to more than one program. In those cases I tried to link it to the most appropriate application. That usually translated into the most widely used app. http://bugs.winehq.org/buglist.cgi?bug_file_loc_type=allwords&bug_file_loc=… About halfway through I created a new Keyword (NoAppDBEntry) to track those bugs that I could not find an AppDB entry for. There are 249 bugs with this keyword. http://bugs.winehq.org/buglist.cgi?keywords_type=allwords&keywords=NoAppDBE… There are a fair number of apps in this list that have more than one bug entered. The one that sticks out in my mind right now is Xilinx, although there were quite a few others. What strikes me most about this, is that as I got to the newer bug reports I ran into more and more esoteric programs. I think that is a good sign. Once Jerry Has committed my bugs.php patch I will consider this bug closed. In order to improve this more requires opening up the source code for our Bugzilla. -- Tony Lambregts PS: Could I get someone to give me more rights in the AppDB. My user name is "tonylambregts" (go figure).

1 0

statvfs and cdrom problem
by Christian Costa 14 Apr '04

14 Apr '04

Hi, I'm trying to make GetFreeDiskSpace working with CDROM because a game needs it. However, I'm experiencing problem with statvfs... Indeed, statvfs always returns f_frsize = 0 and f_blocks = 0. If I cd to /mnt/cdrom or edit a file in it, this does not help however if I run a grep or launch Konqueror in that directory, statvfs magically works. I suspect supermount is responsible because statvfs needs the cdrom to be "physically" mounted. Is it a know issue? (I am on a Mandrake 9.1 base) Or the only solution is to keep a fd opened during the statvfs call so the drive stays mounted... Thanks in advance, Christian PS: I used the attached code for testing #include <sys/types.h> #include <sys/statvfs.h> #include <sys/statfs.h> int main() { struct statvfs info; struct statfs inf; if (statfs("/mnt/cdrom", &inf) < 0) { printf("cannot do statfs\n"); return 0; } printf("size = %ld - %ld\n", inf.f_bsize, inf.f_blocks); if (statvfs("/mnt/cdrom", &info ) < 0) { printf("cannot do statvfs\n"); return 0; } printf("size = %ld - %ld - %ld\n", info.f_bsize, info.f_frsize, info.f_blocks); return 1; }

2 3

Installer crash
by andrejoh＠c2i.net 14 Apr '04

14 Apr '04

When trying to install the game Zoo Tycoon, today's CVS checkout of Wine crashes with the following output: [andrej@rivendell cdrom]$ nice wine ./setup err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report err:wave:OSS_WaveOutInit /dev/mixer1: No such device err:wave:OSS_WaveInInit /dev/mixer1: No such device wine: Unhandled exception (thread 000d), starting debugger... err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report WineDbg starting on pid c Can't find file for ELF 'wine-kthread' ((nil)) Loaded debug information from ELF 'wine-pthread' ((nil)) Breakpoint 1 at 0x0010df00 Loaded debug information from ELF '/home/andrej/local/wine/lib/libwine.so.1' (0x40001000) No debug information in ELF '/lib/tls/libpthread.so.0' ((nil)) No debug information in ELF '/lib/tls/libc.so.6' ((nil)) No debug information in ELF '/lib/libdl.so.2' ((nil)) No debug information in ELF '/lib/ld-linux.so.2' ((nil)) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/ntdll.dll.so' (0x4002c000) Loaded debug information from ELF '/home/andrej/local/wine/lib/libwine_unicode.so.1' (0x40098000) No debug information in ELF '/lib/tls/libm.so.6' ((nil)) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/kernel32.dll.so' (0x402a0000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/user32.dll.so' (0x406c0000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/gdi32.dll.so' (0x407ea000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/advapi32.dll.so' (0x40864000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/winmm.dll.so' (0x40893000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/comctl32.dll.so' (0x408fd000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/shell32.dll.so' (0x40995000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/ole32.dll.so' (0x40a18000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/rpcrt4.dll.so' (0x40a87000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/shlwapi.dll.so' (0x40ace000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/version.dll.so' (0x40b22000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/lz32.dll.so' (0x40b3b000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/imm32.dll.so' (0x40b51000) No debug information in ELF '/usr/lib/libfreetype.so.6' ((nil)) No debug information in ELF '/usr/lib/libz.so.1' ((nil)) No debug information in ELF '/usr/lib/libfontconfig.so.1' ((nil)) No debug information in ELF '/usr/lib/libexpat.so.0' ((nil)) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/x11drv.dll.so' (0x40d90000) No debug information in ELF '/usr/X11R6/lib/libSM.so.6' ((nil)) No debug information in ELF '/usr/X11R6/lib/libICE.so.6' ((nil)) No debug information in ELF '/usr/X11R6/lib/libXv.so.1' ((nil)) No debug information in ELF '/usr/X11R6/lib/libXext.so.6' ((nil)) No debug information in ELF '/usr/X11R6/lib/libX11.so.6' ((nil)) No debug information in ELF '/usr/X11R6/lib/libXcursor.so.1' ((nil)) No debug information in ELF '/usr/X11R6/lib/libXrender.so.1' ((nil)) No debug information in ELF '/usr/X11R6/lib/X11/locale/lib/common/xlcUTF8Load.so.2' (0x40021000) No debug information in ELF '/usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2' (0x40e4c000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/wineoss.drv.so' (0x40e6a000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/msacm.drv.so' (0x40ea6000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/msacm32.dll.so' (0x40ebd000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/midimap.drv.so' (0x40ff0000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/vwin32.vxd.so' (0x41005000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/winedos.dll.so' (0x41330000) No debug information in 32bit DLL 'D:\setup.exe' (0x400000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\NTDLL.DLL' (0x40050000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\KERNEL32.DLL' (0x402d0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\ADVAPI32.DLL' (0x40870000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\GDI32.DLL' (0x40800000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\USER32.DLL' (0x406e0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINMM.DLL' (0x408a0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\COMCTL32.DLL' (0x40910000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RPCRT4.DLL' (0x40aa0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLE32.DLL' (0x40a30000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SHLWAPI.DLL' (0x40af0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SHELL32.DLL' (0x409b0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\LZ32.DLL' (0x40b40000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\VERSION.DLL' (0x40b30000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\IMM32.DLL' (0x40b60000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\X11DRV.DLL' (0x40da0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINEOSS.DRV' (0x40e80000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM32.DLL' (0x40ed0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM.DRV' (0x40eb0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MIDIMAP.DRV' (0x41000000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINEDOS.DLL' (0x41340000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\VWIN32.VXD' (0x41010000) Unhandled exception: page fault on write access to 0x000d0000 in 32-bit code (0x4134b69b). In 32-bit mode. 0x4134b69b (DOSVM_AllocCodeUMB+0x27 [himem.c:121] in WINEDOS.DLL): movw %ax,0x0(%edi) 123 if (selector) Wine-dbg>bt Backtrace: =>0 0x4134b69b (DOSVM_AllocCodeUMB+0x27(size=0x3, segment=0xd0000, selector=0x0) [himem.c:121] in WINEDOS.DLL) (ebp=406be0e4) 1 0x4134b740 (DOSVM_InitSegments+0x2c [himem.c:222] in WINEDOS.DLL) (ebp=406be108) 2 0x4134b017 (DllMain+0x43(hinstDLL=0x41340000, fdwReason=0x1, lpvReserved=0x0) [dosvm.c:725] in WINEDOS.DLL) (ebp=406be11c) 3 0x413470b4 (__wine_dll_main+0x60 [winedos.dll-Iw24bO.spec.c] in WINEDOS.DLL) (ebp=406be14c) 4 0x4009368a (call_dll_entry_point+0x12 in NTDLL.DLL) (ebp=406be164) 5 0x400660cb (MODULE_InitDLL+0xdf(wm=0x401d1370, reason=0x1, lpReserved=0x0) [loader.c:724] in NTDLL.DLL) (ebp=406be1d4) 6 0x40066225 (process_attach+0x81(wm=0x401d1370, lpReserved=0x0) [loader.c:797] in NTDLL.DLL) (ebp=406be1f8) 7 0x400662bf (process_attach+0x11b(wm=0x401d12d0, lpReserved=0x0) [loader.c:789] in NTDLL.DLL) (ebp=406be218) 8 0x400679e4 (LdrLoadDll+0x84(path_name=0x401d1b08, flags=0x0, libname=0x406be27c, hModule=0x406be25c) [loader.c:1529] in NTDLL.DLL) (ebp=406be23c) 9 0x4030dfe7 (load_library+0x4b(libname=0x406be27c, flags=0x0) [module.c:668] in KERNEL32.DLL) (ebp=406be26c) 10 0x4030e0be (LoadLibraryExW+0x2e(libnameW=0x406be32c, hfile=0x0, flags=0x0) [module.c:731] in KERNEL32.DLL) (ebp=406be28c) 11 0x4030e118 (LoadLibraryW+0x1c(libnameW=0x406be32c) [module.c:761] in KERNEL32.DLL) (ebp=406be2a4) 12 0x4033300b (VXD_Open+0x163(filenameW=0x401d1af0, access=0x0, sa=0x0) [vxd.c:192] in KERNEL32.DLL) (ebp=406be358) 13 0x402e2232 (CreateFileW+0x51a(filename=0x401d1ae8, access=0x0, sharing=0x0, sa=0x0, creation=0x3, attributes=0x4000000, template=0x0) [file.c:382] in KERNEL32.DLL) (ebp=406befc4) 14 0x402e2582 (CreateFileA+0x62(filename=0x463fa4, access=0x0, sharing=0x0, sa=0x0, creation=0x3, attributes=0x4000000, template=0x0) [file.c:473] in KERNEL32.DLL) (ebp=406beffc) 15 0x0041b8ac (setup.exe.LaunchGame+0x14bfc in setup.exe) (ebp=00000003) *** Invalid address 0x00000003 (_begin+0x3) My previous compile from CVS (can't remember the date; probably a couple of weeks old) got a lot further, but ended up hanging partway into the installation. This is on Fedora Core 1/i386, with exec-shield turned off. -- Try Anarchy Online http://www.anarchy-online.com/content/downloads/tryout/ Netiquette guidelines ftp://ftp.rfc-editor.org/in-notes/rfc1855.txt How to quote properly http://www.i-hate-computers.demon.co.uk/ Hvordan sitere riktig http://home.online.no/~vidaandr/news/OBSquoting.html

2 4

More serial access issues
by Geoffrey Hausheer 14 Apr '04

14 Apr '04

Well, I broke down and pulled out the oscope and rs232 breakout box to try to figure out why my app isn't able to communicate with the device. turns out that Rein's patch is correctly deasserting DSR, however, I am not getting any data over the Tx pin. And after I checked the output of WriteFile, it is failing. GetLastError doesn't return anything useful (a value of 997 which FormatMessage() can't do anything with). But some debugging led me to determine that NtWriteFile is returning 0x103 which is STATUS_PENDING. After that I'm somewhat lost as to what is going on. Obvioulsy, 'register_new_async' is returning this status, which apparently happens when wine_server_call returns 0 or STATUS_PENDING (not sure if the second is even possible). But about here I am getting completely confused as to what we are trying to accomplish. The file is opened via: CreateFile("COM1", 0, NULL, OPEN_EXISTING, 0, NULL) so we're not in overlapped mode. SetCommTimeout is called with the COMMTIMEOUTS structure containing all 0s. All flow control is disabled using SetCommState. Before a write, we always call 'PurgeComm' and ClearCommError. In Windows, this combination results in a write always occurring when WriteFile is called, regardless of whether there is anything connected to the serial port. Wine appears to be waiting for something, and I'm not sure what. If anyone has any ideas how I might proceed, i'd be glad to hear them. Thanks, .Geoff

1 0

AutoFS-ed drives
by Mark Draheim 14 Apr '04

14 Apr '04

Anybody using autofs and wine? Does it work? I don't follow wine development lists, so maybe autofs is no longer a problem. Once in a while I build a CVS snapshot and test whether the odd app I still have works. And wine on autofs doesn't work here. I think Guido already sent a mail about this last month. Guido patched wine way back in Feb 2003, submitted a bug http://bugs.winehq.com/show_bug.cgi?id=1283 and even set up a page to describe the problem http://freespace.sourceforge.net/guidod/wine-vol-a/ Since then he has completely rewritten the patch in order to search the /etc/auto.* files for drives. This obsoleted the additional options in wine's config with the old patch. This last patch worked perfectly until recently. However, Guido is busy right now and cannot work on the patch. And my C is pretty bad. If anybody is interested I can provide the last patch known to work. If for some reason the patch does not meet wine's standards, would it be possible that the autofs problem is recognized and put on a TODO list for later? Or even close the bug as WONTFIX? thanks Mark

2 2

Re: ISF_MyComputer_fnParseDisplayName()
by Dmitry Timoshkov 14 Apr '04

14 Apr '04

"Martin Fuchs" <martin-fuchs(a)gmx.net> wrote: > Changelog: > make drive letters in PIDLs always uppercase to enable PIDL comparison > > > Index: shfldr_mycomp.c > =================================================================== > RCS file: /CVS/ReactOS/reactos/lib/shell32/shfldr_mycomp.c,v > retrieving revision 1.10 > diff -u -p -d -r1.10 shfldr_mycomp.c > --- shfldr_mycomp.c 11 Apr 2004 13:24:29 -0000 1.10 > +++ shfldr_mycomp.c 13 Apr 2004 20:45:39 -0000 > @@ -217,6 +217,7 @@ ISF_MyComputer_fnParseDisplayName (IShel > /* do we have an absolute path name ? */ > else if (PathGetDriveNumberW (lpszDisplayName) >= 0 && lpszDisplayName[2] == (WCHAR) '\\') { > szNext = GetNextElementW (lpszDisplayName, szElement, MAX_PATH); > + szElement[0] = toupper(szElement[0]); /* make drive letter uppercase to enable PIDL comparison */ It's better to use unicode version here (toupperW) since in some linux locales uppercasing is done differently. -- Dmitry.

3 2

Re: shell32 - file not found
by Juan Lang 14 Apr '04

14 Apr '04

Hi Martin, Martin wrote: > But we could use the expression > "MAKE_HRESULT(SEVERITY_ERROR, FACILITY_WIN32, > ERROR_FILE_NOT_FOUND)" instead. A shorter version is HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND). Question: could you not change _ILCreateFromPathA to return an HRESULT? --Juan __________________________________ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html

2 1

Re: help fixing up SetConsoleCtrlHandler()
by Juan Lang 14 Apr '04

14 Apr '04

Hi Peter, Peter wrote: > 1) If I am using SetLastError, it is not obvious to > me what error values I should be using there. They should be a Win32 error message, the ones defined in winerror.h that aren't HRESULTs (so, lowish values, less then 32000 or so, not 0x80070002-ish). > 2) Can I assume that > Rtl{Enter,Leave}CriticalSection(), > HeapFree(), ERR() and WARN() cannot fail (the latter > two are presumably macros). Mostly yes. If your critical section hasn't been initialized or has been deleted, {Enter,Leave} CriticalSection can hang or otherwise do weird things, but that won't happen "normally". > Should I, either in general, or in this case in > particular, detect which Windows version is being > used and behave appropriately No--write it assuming the less restrictive case. A common way to get partway there is to handle the more restrictive (easier) case, and issue a FIXME and return an error if the caller passes NULL. --Juan __________________________________ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html

1 0

Latest Wine with Corel Office 9
by David Lee Lambert 14 Apr '04

14 Apr '04

I just got around to patching and compiling the '0408 release of Wine, and I notice a few improvements. I tried it out with Corel PerfectOffice 9, of which my family has several copies. Here are my results: WordPerfect hung at the splash screen. Presentations loaded up, but the menu was empty except for "File", and the "Open" item didn't appear to do anything, so I used "Exit" successfully. Quattro Pro quit after a few seconds of the splash screen, giving about a screen of errors: I await thy bidding $ wine qpw.exe err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym 0000 (No Name) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=0,scanCode=0,keycode=8,state=0) err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym 0000 (No Name) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=0,scanCode=0,keycode=8,state=1) err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym FE20 (ISO_Left_Tab) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=9,scanCode=F,keycode=17,state=1) err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym FEF9 (Pointer_EnableKeys) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=90,scanCode=45,keycode=4D,state=1) err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym 0000 (No Name) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=FC,scanCode=0,keycode=0,state=0) err:keyboard:X11DRV_ToUnicodeEx Please report: no char for keysym 0000 (No Name) : err:keyboard:X11DRV_ToUnicodeEx (virtKey=FC,scanCode=0,keycode=0,state=1) fixme:ole:CoRegisterMessageFilter stub fixme:tab:TAB_WindowProc Unimplemented msg TCM_SETEXTENDEDSTYLE fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:ole:CoCreateInstance no classfactory created for CLSID {eab38d25-26dc-11d2-98c0-00104b24170b}, hres is 0x80040154 fixme:storage:StgCreateDocfile Transacted mode not implemented. err:seh:setup_exception stack overflow 0 bytes in thread 0034 eip 401bfc99 esp 40851000 stack 0x40850000-0x40950000 I thought I ought to report the "Please Report" messages; WordPerfect gave similar ones. Is anyone planning to implement CreateAccelleratorTable and related functions any time soon? If not, is there any reason I shouldn't try it? -- resume at http://www.cse.msu.edu/~lamber45/resume.htm PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey

1 0

exec-shield workaround take 4
by Mike McCormack 14 Apr '04

14 Apr '04

Hi again, Here's a fix for the bug that Peter found. The calculation of the reserve area was correct, however the environment was not being cleared correctly, so memory was being reserved for the wrong .exe file. Anybody have a FreeBSD machine to test this on? Mike ----------------------------------------------------------------------- Hi, Here's a new patch for exec-shield. Changes against the last patch: * reserve only the area required by the PE EXE if launched from CreateProcess (else just a default slab) * pass the reserved area to wine, so wine knows about it * unmap the preloader after it is no longer used Again, comments, improvements, flames and test reports are all welcome! Mike ----------------------------------------------------------------------- Hi, This patch works around the exec-shield problems with Fedora Core. I'd be greatful if any people using Fedora core could test it out and see how it works. It should be enough to apply it to the latest CVS tip and recompile. All comments and flames accepted... /me wears his asbestos suit. Mike ChangeLog: * workaround exec-shield by reserving memory before run ld-linux.so.2 Index: dlls/kernel/process.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/process.c,v retrieving revision 1.51 diff -u -r1.51 process.c --- dlls/kernel/process.c 12 Apr 2004 22:12:43 -0000 1.51 +++ dlls/kernel/process.c 14 Apr 2004 08:45:09 -0000 @@ -1059,7 +1059,8 @@ * * Build the environment of a new child process. */ -static char **build_envp( const WCHAR *envW, const WCHAR *extra_envW ) +static char **build_envp( const WCHAR *envW, const WCHAR *extra_envW, + const char *workdir, const char *unixpath ) { const WCHAR *p; char **envp; @@ -1082,7 +1083,7 @@ if (!(env = malloc( length ))) return NULL; WideCharToMultiByte( CP_UNIXCP, 0, envW, p - envW, env, length, NULL, NULL ); - count += 4; + count += 6; if ((envp = malloc( count * sizeof(*envp) ))) { @@ -1097,6 +1098,11 @@ if ((p = getenv("TMP"))) *envptr++ = alloc_env_string( "TMP=", p ); if ((p = getenv("HOME"))) *envptr++ = alloc_env_string( "HOME=", p ); if ((p = getenv("WINEPREFIX"))) *envptr++ = alloc_env_string( "WINEPREFIX=", p ); + + /* record the unix working directory */ + if (workdir) *envptr++ = alloc_env_string( "WINEWORKDIR=", workdir ); + if (unixpath) *envptr++ = alloc_env_string( "WINEPEEXEPATH=", unixpath ); + /* now put the Windows environment strings */ for (p = env; *p; p += strlen(p) + 1) { @@ -1105,6 +1111,8 @@ if (is_special_env_var( p )) /* prefix it with "WINE" */ *envptr++ = alloc_env_string( "WINE", p ); else if (strncmp( p, "HOME=", 5 ) && + strncmp( p, "WINEWORKDIR=", 12 ) && + strncmp( p, "WINEPEEXEPATH=", 14 ) && strncmp( p, "WINEPREFIX=", 11 )) *envptr++ = p; } *envptr = 0; @@ -1135,7 +1143,7 @@ if (!(pid = fork())) /* child */ { char **argv = build_argv( cmdline, 0 ); - char **envp = build_envp( env, NULL ); + char **envp = build_envp( env, NULL, NULL, NULL ); close( fd[0] ); /* Reset signals that we previously set to SIG_IGN */ @@ -1170,14 +1178,8 @@ RTL_USER_PROCESS_PARAMETERS *params; UNICODE_STRING image_str, cmdline_str, desktop, title; NTSTATUS status; - WCHAR buffer[MAX_PATH]; - - if(!GetLongPathNameW( filename, buffer, MAX_PATH )) - lstrcpynW( buffer, filename, MAX_PATH ); - if(!GetFullPathNameW( buffer, MAX_PATH, buffer, NULL )) - lstrcpynW( buffer, filename, MAX_PATH ); - RtlInitUnicodeString( &image_str, buffer ); + RtlInitUnicodeString( &image_str, filename ); RtlInitUnicodeString( &cmdline_str, cmdline ); if (startup->lpDesktop) RtlInitUnicodeString( &desktop, startup->lpDesktop ); if (startup->lpTitle) RtlInitUnicodeString( &title, startup->lpTitle ); @@ -1229,6 +1231,7 @@ pid_t pid; int err; char dummy = 0; + WCHAR buffer[MAX_PATH]; if (!env) { @@ -1236,7 +1239,12 @@ extra_env = DRIVE_BuildEnv(); } - if (!(params = create_user_params( filename, cmd_line, startup ))) + if(!GetLongPathNameW( filename, buffer, MAX_PATH )) + lstrcpynW( buffer, filename, MAX_PATH ); + if(!GetFullPathNameW( buffer, MAX_PATH, buffer, NULL )) + lstrcpynW( buffer, filename, MAX_PATH ); + + if (!(params = create_user_params( buffer, cmd_line, startup ))) { if (extra_env) HeapFree( GetProcessHeap(), 0, extra_env ); return FALSE; @@ -1267,7 +1275,20 @@ if (!(pid = fork())) /* child */ { char **argv = build_argv( cmd_line, 1 ); - char **envp = build_envp( env, extra_env ); + char **envp; + CHAR unixpath[MAX_PATH]; + + unixpath[0]=0; + wine_get_unix_file_name( buffer, unixpath, MAX_PATH ); + + /* preseve the current directory, the preloader may forget it */ + if( !unixdir ) + { + char *dir = HeapAlloc( GetProcessHeap(), 0, MAX_PATH ); + getcwd( dir, MAX_PATH ); + unixdir = dir; + } + envp = build_envp( env, extra_env, unixdir, unixpath ); close( startfd[1] ); close( execfd[0] ); @@ -1279,8 +1300,6 @@ /* Reset signals that we previously set to SIG_IGN */ signal( SIGPIPE, SIG_DFL ); signal( SIGCHLD, SIG_DFL ); - - if (unixdir) chdir(unixdir); if (argv && envp) { Index: libs/wine/config.c =================================================================== RCS file: /home/wine/wine/libs/wine/config.c,v retrieving revision 1.3 diff -u -r1.3 config.c --- libs/wine/config.c 11 Nov 2003 22:21:29 -0000 1.3 +++ libs/wine/config.c 14 Apr 2004 08:45:09 -0000 @@ -243,6 +243,23 @@ return user_name; } +/* run wine binary in it's own directory, so it can find it's preloader */ +int wine_cwd_execve( const char *name, char **argv, char **envp ) +{ + char *dir, *p; + + dir = strdup( name ); + p = strrchr( dir, '/' ); + if( p ) + { + *p++ = 0; + chdir( dir ); + name = p; + } + + return execve( name, argv, envp ); +} + /* exec a wine internal binary (either the wine loader or the wine server) */ /* if name is null, default to the name of the current binary */ void wine_exec_wine_binary( const char *name, char **argv, char **envp ) @@ -257,7 +274,7 @@ argv[0] = xmalloc( sizeof(BINDIR "/") + strlen(name) ); strcpy( argv[0], BINDIR "/" ); strcat( argv[0], name ); - execve( argv[0], argv, envp ); + wine_cwd_execve( argv[0], argv, envp ); free( argv[0] ); /* now try the path of argv0 of the current binary */ @@ -266,7 +283,7 @@ argv[0] = xmalloc( strlen(argv0_path) + strlen(name) + 1 ); strcpy( argv[0], argv0_path ); strcat( argv[0], name ); - execve( argv[0], argv, envp ); + wine_cwd_execve( argv[0], argv, envp ); free( argv[0] ); } @@ -283,7 +300,7 @@ memcpy( argv[0], pos, ptr - pos ); strcpy( argv[0] + (ptr - pos), "/" ); strcat( argv[0] + (ptr - pos), name ); - execve( argv[0], argv, envp ); + wine_cwd_execve( argv[0], argv, envp ); pos = ptr; } free( argv[0] ); Index: loader/Makefile.in =================================================================== RCS file: /home/wine/wine/loader/Makefile.in,v retrieving revision 1.14 diff -u -r1.14 Makefile.in --- loader/Makefile.in 22 Nov 2003 00:08:26 -0000 1.14 +++ loader/Makefile.in 14 Apr 2004 08:45:09 -0000 @@ -23,20 +23,30 @@ LIBPTHREAD = @LIBPTHREAD@ LDEXECFLAGS = @LDEXECFLAGS@ -wine-glibc: glibc.o Makefile.in +WINELDEXECFLAGS = $(LDEXECFLAGS),--dynamic-linker=$(WINELDSO) + +WINELDSO=ld-winepreload.so + +$(WINELDSO): preload.o Makefile.in + $(CC) -nostartfiles -lc -static -Wl,"-Ttext=0x7ff81000" -o $@ $< + +preload.c: preload.h main.h + +wine-glibc: glibc.o Makefile.in $(WINELDSO) $(CC) -o $@ $(LDEXECFLAGS) glibc.o $(LIBWINE) $(LIBPORT) $(LIBPTHREAD) $(EXTRALIBS) $(LDFLAGS) -wine-kthread: $(KTHREAD_OBJS) Makefile.in - $(CC) -o $@ $(LDEXECFLAGS) $(KTHREAD_OBJS) $(LIBWINE) $(LIBPORT) $(EXTRALIBS) $(LDFLAGS) +wine-kthread: $(KTHREAD_OBJS) Makefile.in $(WINELDSO) + $(CC) -o $@ $(WINELDEXECFLAGS) $(KTHREAD_OBJS) $(LIBWINE) $(LIBPORT) $(EXTRALIBS) $(LDFLAGS) -wine-pthread: $(PTHREAD_OBJS) Makefile.in - $(CC) -o $@ $(LDEXECFLAGS) $(PTHREAD_OBJS) $(LIBWINE) $(LIBPORT) $(LIBPTHREAD) $(EXTRALIBS) $(LDFLAGS) +wine-pthread: $(PTHREAD_OBJS) Makefile.in $(WINELDSO) + $(CC) -o $@ $(WINELDEXECFLAGS) $(PTHREAD_OBJS) $(LIBWINE) $(LIBPORT) $(LIBPTHREAD) $(EXTRALIBS) $(LDFLAGS) $(MODULE): $(MAIN_BINARY) $(RM) $(MODULE) && $(LN_S) $(MAIN_BINARY) $(MODULE) install:: $(WINE_BINARIES) $(MKINSTALLDIRS) $(bindir) + $(INSTALL_PROGRAM) $(WINELDSO) $(bindir); \ for f in $(WINE_BINARIES); do \ if [ "$(MAIN_BINARY)" = "$$f" ]; \ then $(INSTALL_PROGRAM) $$f $(bindir)/$(MODULE); \ @@ -48,6 +58,6 @@ $(RM) $(WINE_BINARIES:%=$(bindir)/%) $(bindir)/$(MODULE) clean:: - $(RM) $(WINE_BINARIES) $(MODULE) + $(RM) $(WINE_BINARIES) $(MODULE) $(WINELDSO) ### Dependencies: Index: loader/glibc.c =================================================================== RCS file: /home/wine/wine/loader/glibc.c,v retrieving revision 1.3 diff -u -r1.3 glibc.c --- loader/glibc.c 20 Feb 2004 20:19:23 -0000 1.3 +++ loader/glibc.c 14 Apr 2004 08:45:09 -0000 @@ -75,6 +75,17 @@ { const char *loader = getenv( "WINELOADER" ); const char *threads = get_threading(); + char cwd[MAX_PATH], *cwd_var; + + if( !getcwd( cwd, sizeof cwd ) ) + { + fprintf( stderr, "wine: could get current directory\n" ); + exit(1); + } + cwd_var = xmalloc( sizeof("WINEWORKDIR=") + strlen(cwd) ); + strcpy( cwd_var, "WINEWORKDIR=" ); + strcat( cwd_var, cwd ); + putenv( cwd_var ); if (loader) { @@ -86,6 +97,9 @@ new_name = xmalloc( (path - loader) + strlen(threads) + 1 ); memcpy( new_name, loader, path - loader ); + new_name[ path - loader ] = 0; + if( new_name[0] ) + chdir( new_name ); strcpy( new_name + (path - loader), threads ); /* update WINELOADER with the new name */ Index: loader/main.c =================================================================== RCS file: /home/wine/wine/loader/main.c,v retrieving revision 1.90 diff -u -r1.90 main.c --- loader/main.c 20 Jan 2004 00:28:01 -0000 1.90 +++ loader/main.c 14 Apr 2004 08:45:09 -0000 @@ -20,19 +20,44 @@ #include <stdio.h> #include <stdlib.h> +#include <unistd.h> +#include <sys/mman.h> #include "wine/library.h" +#include "main.h" + +/* this variable is set by the wine-specific shared object loader */ +struct wine_preload_info *wine_preload_vars; + /********************************************************************** * main */ int main( int argc, char *argv[] ) { - char error[1024]; + char error[1024], *dir; + + if( wine_preload_vars ) + { + /* printf("vars(*%p) = %p -> (%p, %08x) (%p, %08x)\n", + &wine_preload_vars, wine_preload_vars, + wine_preload_vars->pe_address, + wine_preload_vars->pe_size, + wine_preload_vars->preload_base, + wine_preload_vars->preload_size ); */ + + /* let wine know which area was mapped */ + wine_set_pe_load_area(wine_preload_vars->pe_address, + wine_preload_vars->pe_size); + + /* unmap the preloader itself */ + munmap( wine_preload_vars->preload_base, + wine_preload_vars->preload_size ); + wine_preload_vars = NULL; + } -#if 0 - static char pe_load[256*1024*1024] __attribute__((aligned(4096))); - wine_set_pe_load_area( pe_load, sizeof(pe_load) ); -#endif + dir = getenv( "WINEWORKDIR" ); + if( dir ) + chdir( dir ); wine_init( argc, argv, error, sizeof(error) ); fprintf( stderr, "wine: failed to initialize: %s\n", error ); --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ loader/main.h 2004-04-11 16:58:25.000000000 +0900 @@ -0,0 +1,8 @@ + +struct wine_preload_info +{ + void *pe_address; + size_t pe_size; + void *preload_base; + size_t preload_size; +}; --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ loader/preload.h 2004-04-11 16:58:25.000000000 +0900 @@ -0,0 +1,51 @@ +/* + mini loader for ld.so - x86 Linux 2.4.x+ kernels only + + Copyright 2004 Mike McCormack for Codeweavers + + Copyright (C) 1995,96,97,98,99,2000,2001,2002 Free Software Foundation, Inc. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + 02111-1307 USA. + */ + +#define LDSO_NAME "/lib/ld-linux.so.2" + +/* ELF definitions */ +#define ELF_PREFERRED_ADDRESS(loader, maplength, mapstartpref) (mapstartpref) +#define ELF_FIXED_ADDRESS(loader, mapstart) ((void) 0) + +#define __ELF_NATIVE_CLASS 32 +#define MAP_BASE_ADDR(l) 0 +#define MAP_COPY MAP_PRIVATE +#define ANONFD -1 + +#define ElfW(type) _ElfW (Elf, __ELF_NATIVE_CLASS, type) +#define _ElfW(e,w,t) _ElfW_1 (e, w, _##t) +#define _ElfW_1(e,w,t) e##w##t + +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <unistd.h> +#include <sys/mman.h> +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> + +#define GL(x) x + +extern unsigned int GL(dl_pagesize); + --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ loader/preload.c 2004-04-11 16:58:25.000000000 +0900 @@ -0,0 +1,727 @@ +/* + mini loader for ld.so - x86 Linux 2.4.x+ kernels only + + Copyright 2004 Mike McCormack for Codeweavers + + Copyright (C) 1995,96,97,98,99,2000,2001,2002 Free Software Foundation, Inc. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + 02111-1307 USA. + */ + +/* + * Design notes + * + * The goal of this program is to be a workaround for exec-shield, as used + * by the Linux kernel distributed with Fedora Core and other distros. + * + * To do this, we implement our own shared object loader that reserves memory + * that is important to Wine, and then loads the the standard shared object + * loader (ELF interpreter), usually ld-linux.so.2 + * + * This program will be invoked by linking it as the shared object loader + * using the link time flags --shared-loader=ld-winepreload.so . Since we + * are not using an absolute path, an executable using this shared object + * loader must be invoked from the directory that contains this loader. + * + * We will try to set up the stack an memory area so that the program that + * loads after us (eg. the wine binary) never knows we were here, except that + * areas of memory it needs are already magically reserved. + * + * The following memory areas are important to Wine: + * 0x00000000 - the DOS area + * 0x00400000 - the standard Win32 load address + * 0x65430000 - the shared heap + * + * If this program is used as the shared object loader. the only difference + * that the loaded programs should see is that this loader will be mapped + * into memory when it starts. + * + * Limitations: + * * using a non-absolution path for the shared object loader is not standard + */ + +/* + * References (things I consulted to understand how ELF loading works): + * + * glibc 2.3.2 elf/dl-load.c + * http://www.gnu.org/directory/glibc.html + * + * Linux 2.6.4 fs/binfmt_elf.c + * ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.4.tar.bz2 + * + * Userland exec, by <grugq(a)hcunix.net> + * http://cert.uni-stuttgart.de/archive/bugtraq/2004/01/msg00002.html + * + * The ELF specification: + * http://www.linuxbase.org/spec/booksets/LSB-Embedded/LSB-Embedded/book387.ht… + */ + +#include "preload.h" +#include "main.h" +#include <elf.h> + +/* the following headers are needed to get the definition for IMAGE_NT_HEADERS */ +#include <stdarg.h> +#include "windef.h" +#include "winbase.h" + +/* debugging */ +#undef DUMP_SEGMENTS +#undef DUMP_ARG +#undef DUMP_AUX_INFO +#undef DUMP_SYMS + +unsigned int GL(dl_pagesize) = 0x0000; +extern const unsigned char _end[]; + +struct link_map { + ElfW(Addr) l_addr; + ElfW(Dyn) *l_ld; + const ElfW(Phdr) *l_phdr; + ElfW(Addr) l_entry; + ElfW(Half) l_ldnum; + ElfW(Half) l_phnum; + ElfW(Addr) l_map_start, l_map_end; +}; + +/* + * wld_printf - just the basics + * + * %x prints a hex number + * %s prints a string + */ +void wld_sprintf(char *str, char *fmt, int *args ) +{ + char *p = fmt; + + while( *p ) + { + if( *p == '%' ) + { + p++; + if( *p == 'x' ) + { + int ch, i, x = *++args; + for(i=7; i>=0; i--) + { + ch = (x>>(i*4))&0xf; + ch += '0'; + if(ch>'9') + ch+=('A'-10-'0'); + *str++ = ch; + } + } + else if( *p == 's' ) + { + char *s = (char*)*++args; + while(*s) + *str++ = *s++; + } + else if( *p == 0 ) + break; + p++; + } + *str++ = *p++; + } + *str = 0; +} + +int wld_strlen(char *str) +{ + int n = 0; + while( str[n] ) + n++; + return n; +} + +void wld_printf(char *fmt, ... ) +{ + char buffer[100]; + int n; + + buffer[0]=0; + wld_sprintf(buffer, fmt, (int*)&fmt ); + n = wld_strlen( buffer ); + write(2, buffer, n); +} + +void wld_strncpy(char *dest, char *src, int count ) +{ + while( (*dest++ = *src++) && --count ) + ; + *dest = 0; +} + +void wld_memset( unsigned char *buf, int val, size_t len ) +{ + while( len-- ) + *buf++=val; +} + +#ifdef DUMP_AUX_INFO +/* + * Dump interesting bits of the ELF auxv_t structure that is passed + * as the 4th parameter to the _start function + */ +static void wld_dump_auxilary( ElfW(auxv_t) *av ) +{ + for ( ; av->a_type != AT_NULL; av++) + switch (av->a_type) + { + case AT_PAGESZ: + wld_printf("AT_PAGESZ = %x\n",av->a_un.a_val); + break; + case AT_PHDR: + wld_printf("AT_PHDR = %x\n",av->a_un.a_ptr); + break; + case AT_PHNUM: + wld_printf("AT_PHNUM = %x\n",av->a_un.a_val); + break; + case AT_ENTRY: + wld_printf("AT_ENTRY = %x\n",av->a_un.a_val); + break; + case AT_BASE: + wld_printf("AT_BASE = %x\n",av->a_un.a_val); + break; + } +} +#endif + +/* + * wld_set_auxilary + * + * Set a field of the auxillary structure + */ +void wld_set_auxilary( ElfW(auxv_t) *av, int type, long int val ) +{ + for ( ; av->a_type != AT_NULL; av++) + if( av->a_type == type ) + av->a_un.a_val = val; +} + +/* + * wld_get_auxilary + * + * Get a field of the auxillary structure + */ +int wld_get_auxilary( ElfW(auxv_t) *av, int type, int *val ) +{ + for ( ; av->a_type != AT_NULL; av++) + if( av->a_type == type ) + { + *val = av->a_un.a_val; + return 1; + } + return 0; +} + +/* + * wld_map_so + * + * modelled after _dl_map_object_from_fd() from glibc-2.3.1/elf/dl-load.c + * + * This function maps the segments from an ELF object, and optionally + * stores information about the mapping into the auxv_t structure. + */ +void* wld_map_so( int fd, void* buf, size_t buflen, struct link_map *l) +{ + ElfW(Ehdr) *header = buf; + ElfW(Phdr) *phdr, *ph; + /* Scan the program header table, collecting its load commands. */ + struct loadcmd + { + ElfW(Addr) mapstart, mapend, dataend, allocend; + off_t mapoff; + int prot; + } loadcmds[header->e_phnum], *c; + size_t nloadcmds = 0, maplength; + + header = buf; + phdr = (void*) (((unsigned char*)buf) + header->e_phoff); + + if( header->e_ident[0] != 0x7f && + header->e_ident[0] != 'E' && + header->e_ident[0] != 'L' && + header->e_ident[0] != 'F' ) + { + wld_printf("Not an ELF binary... don't know how to load it\n"); + return NULL; + } + + if( header->e_machine != EM_386 ) + { + wld_printf("Not an i386 ELF binary... don't know how to load it\n"); + return NULL; + } + + maplength = header->e_phnum * sizeof (ElfW(Phdr)); + if (header->e_phoff + maplength > (size_t) buflen) + { + wld_printf("oops... not enough space for ELF headers\n"); + exit(1); + } + + l->l_ld = 0; + l->l_addr = 0; + l->l_phnum = header->e_phnum; + l->l_entry = header->e_entry; + + for (ph = phdr; ph < &phdr[l->l_phnum]; ++ph) + { + +#ifdef DUMP_SEGMENTS + wld_printf( "ph = %x\n", ph ); + wld_printf( " p_type = %x\n", ph->p_type ); + wld_printf( " p_flags = %x\n", ph->p_flags ); + wld_printf( " p_offset = %x\n", ph->p_offset ); + wld_printf( " p_vaddr = %x\n", ph->p_vaddr ); + wld_printf( " p_paddr = %x\n", ph->p_paddr ); + wld_printf( " p_filesz = %x\n", ph->p_filesz ); + wld_printf( " p_memsz = %x\n", ph->p_memsz ); + wld_printf( " p_align = %x\n", ph->p_align ); +#endif + + switch (ph->p_type) + { + /* These entries tell us where to find things once the file's + segments are mapped in. We record the addresses it says + verbatim, and later correct for the run-time load address. */ + case PT_DYNAMIC: + l->l_ld = (void *) ph->p_vaddr; + l->l_ldnum = ph->p_memsz / sizeof (Elf32_Dyn); + break; + + case PT_PHDR: + l->l_phdr = (void *) ph->p_vaddr; + break; + + case PT_TLS: + /* + * We don't need to set anything up because we're + * emulating the kernel, not ld-linux.so.2 + * The ELF loader will set up the TLS data itself. + */ + break; + + case PT_LOAD: + { + if ((ph->p_align & (GL(dl_pagesize) - 1)) != 0) + { + wld_printf("ELF load command alignment not page-aligned"); + return NULL; + } + if (((ph->p_vaddr - ph->p_offset) & (ph->p_align - 1)) != 0) + { + wld_printf("ELF load command address/offset not properly aligned"); + return NULL; + } + + c = &loadcmds[nloadcmds++]; + c->mapstart = ph->p_vaddr & ~(ph->p_align - 1); + c->mapend = ((ph->p_vaddr + ph->p_filesz + GL(dl_pagesize) - 1) + & ~(GL(dl_pagesize) - 1)); + c->dataend = ph->p_vaddr + ph->p_filesz; + c->allocend = ph->p_vaddr + ph->p_memsz; + c->mapoff = ph->p_offset & ~(ph->p_align - 1); + + c->prot = 0; + if (ph->p_flags & PF_R) + c->prot |= PROT_READ; + if (ph->p_flags & PF_W) + c->prot |= PROT_WRITE; + if (ph->p_flags & PF_X) + c->prot |= PROT_EXEC; + } + break; + + case PT_INTERP: + break; + + case PT_SHLIB: + case PT_NOTE: + case PT_GNU_EH_FRAME: + case 0x6474e551: /* FIXME: what is this? */ + break; + + default: + wld_printf("warning: unknown header type %x\n", ph->p_type); + break; + } + } + + /* Now process the load commands and map segments into memory. */ + c = loadcmds; + + /* Length of the sections to be loaded. */ + maplength = loadcmds[nloadcmds - 1].allocend - c->mapstart; + + if( header->e_type == ET_DYN ) + { + ElfW(Addr) mappref; + mappref = (ELF_PREFERRED_ADDRESS (loader, maplength, c->mapstart) + - MAP_BASE_ADDR (l)); + + /* Remember which part of the address space this object uses. */ + l->l_map_start = (ElfW(Addr)) mmap ((void *) mappref, maplength, + c->prot, MAP_COPY | MAP_FILE, + fd, c->mapoff); + /* wld_printf("set : offset = %x\n", c->mapoff); */ + /* wld_printf("l->l_map_start = %x\n", l->l_map_start); */ + + l->l_map_end = l->l_map_start + maplength; + l->l_addr = l->l_map_start - c->mapstart; + + mprotect ((caddr_t) (l->l_addr + c->mapend), + loadcmds[nloadcmds - 1].allocend - c->mapend, + PROT_NONE); + goto postmap; + } + else + { + ELF_FIXED_ADDRESS (loader, c->mapstart); + } + + /* Remember which part of the address space this object uses. */ + l->l_map_start = c->mapstart + l->l_addr; + l->l_map_end = l->l_map_start + maplength; + + while (c < &loadcmds[nloadcmds]) + { + if (c->mapend > c->mapstart) + /* Map the segment contents from the file. */ + mmap ((void *) (l->l_addr + c->mapstart), + c->mapend - c->mapstart, c->prot, + MAP_FIXED | MAP_COPY | MAP_FILE, fd, c->mapoff); + + postmap: + if (l->l_phdr == 0 + && (ElfW(Off)) c->mapoff <= header->e_phoff + && ((size_t) (c->mapend - c->mapstart + c->mapoff) + >= header->e_phoff + header->e_phnum * sizeof (ElfW(Phdr)))) + /* Found the program header in this segment. */ + l->l_phdr = (void *) (c->mapstart + header->e_phoff - c->mapoff); + + if (c->allocend > c->dataend) + { + /* Extra zero pages should appear at the end of this segment, + after the data mapped from the file. */ + ElfW(Addr) zero, zeroend, zeropage; + + zero = l->l_addr + c->dataend; + zeroend = l->l_addr + c->allocend; + zeropage = ((zero + GL(dl_pagesize) - 1) + & ~(GL(dl_pagesize) - 1)); + + /* + * This is different to the dl-load load... + * ld-linux.so.2 relies on the whole page being zero'ed + */ + zeroend = (zeroend +GL(dl_pagesize) - 1) & ~(GL(dl_pagesize) - 1); + + if (zeroend < zeropage) + { + /* All the extra data is in the last page of the segment. + We can just zero it. */ + zeropage = zeroend; + } + + if (zeropage > zero) + { + /* Zero the final part of the last page of the segment. */ + if ((c->prot & PROT_WRITE) == 0) + { + /* Dag nab it. */ + mprotect ((caddr_t) (zero & ~(GL(dl_pagesize) - 1)), + GL(dl_pagesize), + c->prot|PROT_WRITE); + } + memset ((void *) zero, '\0', zeropage - zero); + if ((c->prot & PROT_WRITE) == 0) + mprotect ((caddr_t) (zero & ~(GL(dl_pagesize) - 1)), + GL(dl_pagesize), c->prot); + } + + if (zeroend > zeropage) + { + /* Map the remaining zero pages in from the zero fill FD. */ + caddr_t mapat; + mapat = mmap ((caddr_t) zeropage, zeroend - zeropage, + c->prot, MAP_ANON|MAP_PRIVATE|MAP_FIXED, + ANONFD, 0); + } + } + + ++c; + } + + if (l->l_phdr == NULL) + { + wld_printf("no program header\n"); + exit(1); + } + + (ElfW(Addr)) l->l_phdr += l->l_addr; + (ElfW(Addr)) l->l_entry += l->l_addr; + + return (void*)l->l_entry; +} + +#define ROUND_SIZE(addr,size) \ + (((int)(size) + ((int)(addr) & page_mask) + page_mask) & ~page_mask) + +/* + * wld_reserve_wine_memory + * + * This is the reason we are here. + * We want to reserve address space so that the kernel doesn't + * map stuff there. We do this by getting in first before + * anything else is mapped (except this program) and reserve + * the memory we want. + */ +void wld_reserve_wine_memory( char *pe_file, void **base, size_t *size ) +{ + IMAGE_DOS_HEADER dos; + IMAGE_NT_HEADERS nt; + int unix_fd, page_mask = GL(dl_pagesize) - 1; + + if( !pe_file ) + return; + + unix_fd = open( pe_file, O_RDONLY, 0); + if( unix_fd < 0 ) + return; + + /* + * The following code is borrowed from + * get_image_params() in wine/server/mapping.c + */ + if (read( unix_fd, &dos, sizeof(dos) ) != sizeof(dos)) goto error; + if (dos.e_magic != IMAGE_DOS_SIGNATURE) goto error; + if (lseek( unix_fd, dos.e_lfanew, SEEK_SET ) == -1) goto error; + + if (read( unix_fd, &nt.Signature, sizeof(nt.Signature) ) != sizeof(nt.Signature)) goto error; + if (nt.Signature != IMAGE_NT_SIGNATURE) goto error; + if (read( unix_fd, &nt.FileHeader, sizeof(nt.FileHeader) ) != sizeof(nt.FileHeader)) goto error; + /* zero out Optional header in the case it's not present or partial */ + memset(&nt.OptionalHeader, 0, sizeof(nt.OptionalHeader)); + if (read( unix_fd, &nt.OptionalHeader, nt.FileHeader.SizeOfOptionalHeader) != nt.FileHeader.SizeOfOptionalHeader) goto error; + + *size = ROUND_SIZE( 0, nt.OptionalHeader.SizeOfImage ); + *base = (void *)nt.OptionalHeader.ImageBase; + +#ifdef DUMP_PERESERVE + wld_printf( "parsed PE image... base %x size %x\n", *base, *size ); +#endif + +error: + close( unix_fd ); +} + +/* + * Find a symbol in the symbol table of the executable loaded + */ +void *wld_find_symbol( const ElfW(Phdr) *phdr, int num, char *var ) +{ + const ElfW(Dyn) *dyn = NULL; + void *ptr = NULL; + const ElfW(Phdr) *ph; + const ElfW(Sym) *symtab = NULL; + const char *strings = NULL; + + /* check the values */ +#ifdef DUMP_SYMS + wld_printf("%x %x\n", phdr, num ); +#endif + if( ( phdr == NULL ) || ( num == 0 ) ) + { + wld_printf("could not find PT_DYNAMIC header entry\n"); + return NULL; + } + + /* parse the (already loaded) ELF executable's header */ + for (ph = phdr; ph < &phdr[num]; ++ph) + { + if( PT_DYNAMIC == ph->p_type ) + { + dyn = (void *) ph->p_vaddr; + num = ph->p_memsz / sizeof (Elf32_Dyn); + break; + } + } + if( !dyn ) + { + wld_printf("No PT_DYNAMIC section\n"); + return ptr; + } + + while( dyn->d_tag ) + { + if( dyn->d_tag == DT_STRTAB ) + strings = (const char*) dyn->d_un.d_ptr; + if( dyn->d_tag == DT_SYMTAB ) + symtab = (const ElfW(Sym) *)dyn->d_un.d_ptr; +#ifdef DUMP_SYMS + wld_printf("%x %x\n", dyn->d_tag, dyn->d_un.d_ptr ); +#endif + dyn++; + } + + if( (!symtab) || (!strings) ) + { + wld_printf("No symbol table found\n"); + return ptr; + } + + /* FIXME: this crashes if it doesn't find the symbol we want */ + do + { + if( ( ELF32_ST_BIND(symtab->st_info) == STT_OBJECT ) && + ( 0 == strcmp( strings+symtab->st_name, var ) ) ) + { + ptr = (void*)symtab->st_value; + break; + } + symtab++; + } + while( symtab->st_name ); + +#ifdef DUMP_SYMS + wld_printf("Found %s -> %x\n", strings+symtab->st_name, symtab->st_value ); +#endif + + return ptr; +} + +/* + * wld_start + * + * Repeat the actions the kernel would do when loading a dynamically linked .so + * Load the ELF interperter ld-linux.so and then binary itself. + * + * Note, we assume that the binary is a dynamically linked ELF shared object + * and that ld-linux.so is its ELF interpreter. + */ +void* wld_start( int argc ) +{ + int fd, phnum = 0; + unsigned char buf[0x800]; + void *start; + char **argv = (char**) &argc, **p, *pe_file = NULL; + struct link_map map; + ElfW(auxv_t)* av; + ElfW(Phdr) *elf_phdr = NULL; + struct wine_preload_info **wine_preload_vars; + static struct wine_preload_info vars; + + memset( &map, 0, sizeof map ); + + /* skip over the parameters */ + p = ++argv; +#ifdef DUMP_ARG + { + int i; + for( i = 0; i<argc; i++ ) + wld_printf("argv[%x] = %s\n", i, *p++); + if(*p++) + wld_printf("argv[argc] not NULL!!\n"); + } +#else + p+=(argc+1); +#endif + + /* skip over the environment, find the name of the PE file */ + while( *p ) + { + const char pefile[] = "WINEPEEXEPATH="; + if( 0 == memcmp( pefile, *p, sizeof pefile - 1 ) ) + pe_file = (*p) + sizeof pefile - 1 ; + p++; + } + + av = (ElfW(auxv_t)*) (p+1); + wld_get_auxilary( av, AT_PAGESZ, &dl_pagesize ); +#ifdef DUMP_AUX_INFO + wld_dump_auxilary( av ); +#endif + + /* reserve memory that Wine needs */ + vars.pe_size = 0x01000000; + vars.pe_address = (void*)0x00400000; + wld_reserve_wine_memory( pe_file, &vars.pe_address, &vars.pe_size ); + mmap( vars.pe_address, vars.pe_size, PROT_NONE, + MAP_FIXED|MAP_PRIVATE|MAP_ANON, -1, 0); + + /* load the original dynamic loader itself */ + fd = open( LDSO_NAME, O_RDONLY, 0); + if( fd < 0 ) + { + wld_printf( "error: fd = %x\n", fd); + exit(1); + } + read( fd, buf, sizeof buf ); + start = wld_map_so( fd, buf, sizeof buf, &map ); + if( !start ) + exit(0); + close( fd ); + + /* + * Pass information to the wine loader in a static variable + * so it doesn't get destroyed after we leave this stack frame + */ + wld_get_auxilary( av, AT_PHDR, (int*)&elf_phdr ); + wld_get_auxilary( av, AT_PHNUM, (int*)&phnum ); + wine_preload_vars = wld_find_symbol( elf_phdr, phnum, "wine_preload_vars" ); + if( wine_preload_vars ) + { + unsigned char *base = (void*)0x7ff81000; /* FIXME - define properly */ + vars.preload_base = (void*) base; + vars.preload_size = (size_t) (_end - base); + *wine_preload_vars = &vars; + } + + wld_set_auxilary( av, AT_BASE, map.l_addr ); + +#ifdef DUMP_AUX_INFO + wld_printf("New auxillary info:\n"); + wld_dump_auxilary( av ); + wld_printf("jumping to %x\n", start); +#endif + + return start; +} + +/* + * The _start function is the entry and exit point of this program + * + * It calls wld_start, passing a pointer to the args it receives + * then jumps to the address wld_start returns after removing the + * first argv[] value, and decrementing argc + */ +void _start(void); +__asm ( + ".align 4\n" + "\t.global _start\n" + "\t.type _start,@function\n" +"_start:\n" + "\tcall wld_start\n" + "\tpush %eax\n" + "\txor %eax,%eax\n" + "\txor %ebx,%ebx\n" + "\txor %ecx,%ecx\n" + "\txor %edx,%edx\n" + "\tret\n" +); +

2 2

Re: Remove "Path" lines from sample config
by Saulius Krasuckas 14 Apr '04

14 Apr '04

> Changelog: > Remove "Path" lines from sample config. > Setup the links for the default DOS drives in wineinstall. hey, it is plain and simple change but it makes me disappointed right after second reinstall of Wine. GNU ln when encounters existing target (link to directory, in fact) creates a sym-link with the name of original target already in mentioned symlinked dir. that we are getting is like a: ln: `/home/s2/.wine/dosdevices/c:/c': File exists and this: lrwxrwxrwx 1 s2 s2 10 Apr 14 15:36 /home/s2/.wine/dosdevices/c: -> /home/s2/c lrwxrwxrwx 1 s2 s2 10 Apr 14 15:58 /home/s2/.wine/dosdevices/c:/c -> /home/s2/c as that does not belong to Wine binary (it is more to config of Wine-user), i'd not like to change existing dosdevices/ symlinks during "make uninstall" or even "tools/wineinstall". OK, maybe target should only be removed if it is not a symlink. so, what about some additional small bash function? Index: wine/tools/wineinstall =================================================================== RCS file: /home/wine/wine/tools/wineinstall,v retrieving revision 1.67 diff -u -r1.67 wineinstall --- wine/tools/wineinstall 12 Apr 2004 22:05:00 -0000 1.67 +++ wine/tools/wineinstall 14 Apr 2004 14:54:05 -0000 @@ -140,6 +140,16 @@ link_app winebrowser "$CROOT/windows/winebrowser.exe" } +function link_file_safely { + # makes link to target if link does not exist already + # parameters: + # $1 - path to target, + # $2 - path to link name + if [ -L $2 ]; then return 1; fi + if [ -e $2 ]; then return 2; fi + ln -s $1 $2 +} + # startup... echo "WINE Installer v0.74" @@ -600,12 +610,12 @@ echo "Preparing to install default Wine registry entries..." # Make sure we are on a Windows drive - ln -s /mnt/fd0 ~/.wine/dosdevices/a: - ln -s $CROOT ~/.wine/dosdevices/c: - ln -s /cdrom ~/.wine/dosdevices/d: - ln -s /tmp ~/.wine/dosdevices/e: - ln -s ~ ~/.wine/dosdevices/f: - ln -s / ~/.wine/dosdevices/z: + link_file_safely /mnt/fd0 ~/.wine/dosdevices/a: + link_file_safely $CROOT ~/.wine/dosdevices/c: + link_file_safely /cdrom ~/.wine/dosdevices/d: + link_file_safely /tmp ~/.wine/dosdevices/e: + link_file_safely ~ ~/.wine/dosdevices/f: + link_file_safely / ~/.wine/dosdevices/z: echo "Installing default Wine registry entries..." echo PS and yes, that double check in "link_file_safely" function (one for existing target/link with a given name and second about target being some file of other kind) may be overhead. PPS IMHO it could be nice to eliminate overhead of multiple passing string "~/.wine/dosdevices/" by assigning its value to some script variable and by putting out that block into separate function, say some "mk_dosdevices" or like. ughm?

1 0

Re: exec-shield workaround take 4
by Mike Hearn 14 Apr '04

14 Apr '04

On Wed, 14 Apr 2004 18:44:45 +0900, Mike McCormack wrote: > Anybody have a FreeBSD machine to test this on? If it still uses syscalls surely that won't work on anything other than Linux?

2 1

RE: Handling dialog messages for non-template based dialogs
by Santosh Siddheshwar 14 Apr '04

14 Apr '04

Thanks for the feedback. Excellent catches! Hope my next mail to wine-patches gets through! Regards Santosh Siddheshwar > -----Original Message----- > From: Dmitry Timoshkov [SMTP:dmitry@baikal.ru] > Sent: Tuesday, April 13, 2004 7:38 PM > To: Santosh Siddheshwar; Robert Shearman; wine-devel(a)winehq.org > Cc: santosh.s(a)sonata-software.com > Subject: Re: Handling dialog messages for non-template based dialogs > > "Santosh Siddheshwar" <santosh.s(a)sonata-software.com> wrote: > > > I didnt get the second point that you mention > > Another one might be that WM_CREATE must be always > > passed to DEFDLG_Proc regardless of what result an application > > returned to DefDlgProc16/A/W. > > Here is a snippet of DefDlgProc16 (DefDlgProcA/W are the same): > > LRESULT WINAPI DefDlgProc16( HWND16 hwnd, UINT16 msg, WPARAM16 wParam, > LPARAM lParam ) > { > WNDPROC16 dlgproc; > HWND hwnd32 = WIN_Handle32( hwnd ); > BOOL result = FALSE; > > ===== > Perhaps WM_CREATE handling code should be moved here: > if (msg == WM_CREATE) > { > wndPtr->flags |= WIN_ISDIALOG; > blah-blah-blah > } > ===== > > SetWindowLongW( hwnd32, DWL_MSGRESULT, 0 ); > > if ((dlgproc = (WNDPROC16)DEFDLG_GetDlgProc( hwnd32 ))) > { > /* Call dialog procedure */ > result = CallWindowProc16( dlgproc, hwnd, msg, wParam, lParam ); > /* 16 bit dlg procs only return BOOL16 */ > if( WINPROC_GetProcType( (WNDPROC)dlgproc ) == WIN_PROC_16 ) > result = LOWORD(result); > } > > if (!result && IsWindow(hwnd32)) <== here we check whether an app > handled the message > { > /* callback didn't process this message */ > > switch(msg) > { > case WM_ERASEBKGND: > > Probably WM_CREATE handling should be performed even before control > is passed to an application. > > -- > Dmitry. ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

2 1

Game support
by James Perry 14 Apr '04

14 Apr '04

Hi everyone, I've been following Wine development for a while but now I think it's time to contribute something. I don't use Windows anymore (except for PowerPoint at work), but I decided it would be good to be able to play some games on Linux. So I grabbed Wine from CVS, compiled it up and tested some games, with the intention of finding where the problems were and hopefully fixing them. I have put my results on a web page at: http://www.epcc.ed.ac.uk/~jamesp/wine-games.html to avoid making this posting even longer. Note that I haven't looked in detail at most of these yet, I just tried them out once to see what would happen. I'm gradually working through the list, debugging them. I've already submitted one patch (to solve a D3D blend mode problem that affected SonicR). I have traced a number of the other problems to specific aspects of Wine, but I'm not sure how to go about fixing them. Any advice on these points from experienced developers would be welcome: 1. MusicVR exits with this error: X Error of failed request: GLXBadDrawable Major opcode of failed request: 145 (GLX) Minor opcode of failed request: 11 (X_GLXSwapBuffers) Serial number of failed request: 10522 Current serial number in output stream: 10523 I traced it to the line: glXMakeCurrent(default_display, None, NULL) in dlls/opengl32/wgl.c. My OpenGL (nVidia) doesn't seem to like the drawable being set to None, although according to the GLX docs, this should be OK. Simply commenting out the line makes the game work fine, but I don't think this is the right fix. Any ideas? 2. Settlers III crashes almost straight away, in the code of the PE-Crypt protection system. This is caused by the processor's direction flag (which controls whether pointers are incremented or decremented by string instructions) getting reset somewhere, probably in Wine code. Can anyone comment on treatment of this flag in Wine? Is it likely to be clobbered in lots of places? Basically, is there any hope of getting this working? I'm not sure where to start with this one. 3. South Park Rally creates its DirectInput object using the generic OLE functions, which doesn't work in Wine right now. I have some initial code to support this, but not sure if it does everything it needs to. I have: - copied regsvr.c from the DirectSound DLL and edited it to register the DirectInput classes, and implement the DirectInput Dll[Un]RegisterServer methods - removed the stubs of those functions from dinput_main.c - added regsvr.c to the list of source files in dinput's Makefile.in, and added ole32 and advapi32 to the list of imports It would also be good if the default registry created by winebuild contained the necessary entries to make this work (I had to add them by hand), but I couldn't find where the initial registry entries come from. If this all sounds OK, I can submit it as a patch. Although even with this support, South Park Rally fails with another DirectX problem. One step at a time though... 4. The CD audio in Sonic 3D doesn't play in Wine yet. I found there were two separate problems causing this. First, it's trying to use CD device 2. No idea where this number comes from, as I have only one CD-ROM in the system, and the game doesn't seem to be specifying device 2 anywhere. Anyone know where mcicda gets the device ID from, save me spending ages looking for it? Second, it's using TMSF (track,minutes,seconds,frames) format to specify locations on the CD. These appear as colon-separated values in the MCI commands (e.g. "02:00:00") but the argument parser chokes on them, expecting a single integer. I got around this by hacking MCI_GetDWord to recognise the colons and parse these arguments correctly, but maybe that's not the way to do it... any suggestions? Sorry this post is so long. Finally, I'd just like to say great job everyone! I was impressed that things like DirectX, InstallShield and even SecuROM copy protection are working so well - they're flawless on some of the games I tried. It's really come on since I first tried it back in 2000. Cheers, James

6 12

Re: shell32 - file not found
by Uwe Bonnes 14 Apr '04

14 Apr '04

>>>>> "Martin" == Martin Fuchs <martin-fuchs(a)gmx.net> writes: Martin> Changelog: return "file not found" error values instead of Martin> E_INVALIDARG if _ILCreateFromPathA() failed to find files ... Martin> 0x80070002L; /* file not found */ } else { pidlTemp = ... Don't we have a symbolic error for that? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

(no subject)
by j.cooper1＠comcast.net 13 Apr '04

13 Apr '04

I am trying to compile Wine (the latest CVS) on Mac os x. If I emailed the wrong list sorry I noticed what I think is a bug in file dll/kernel/console.c around line 1003 exists function below when compiling it gives me an error about x being undefined or something similar COORD WINAPI GetLargestConsoleWindowSize(HANDLE hConsoleOutput) { COORD c; c.X = 80; c.Y = 24; TRACE("(%p), returning %dx%d\n", hConsoleOutput, c.X, x.Y); return c; } #endif /* defined(__i386__) */ Changing the x.Y to c.X seems to fix the problem COORD WINAPI GetLargestConsoleWindowSize(HANDLE hConsoleOutput) { COORD c; c.X = 80; c.Y = 24; TRACE("(%p), returning %dx%d\n", hConsoleOutput, c.X, x.Y); return c; } I am not a programmer nor do I know how to create a patch or if I am correct in my assumptions. Could some one please help me out? Jeff ps.. I now get an error compiling dbghelp. I am not on the computer I am compiling on so I can't copy and paste the error. If there are typos in the error that is because I am copying the code by typing it up elf_module.c:627: error: previous declaration of 'elf_read_wine_loader_dbg_info' dbghelp_private.h:275: error: previous declaration of 'elf_read_wine_loader_dbg_info' elf module.c:71: warning: '__wine_dbch___default' defined but not used make[2]: *** [elf_module.o] Error 1 make[1]: *** [dbghelp] Error 2 make: *** [dlls] Error 2

2 1

RE: CryptoAPI
by Juan Lang 13 Apr '04

13 Apr '04

Hi Robert, Robert wrote: > It depends on which part you are trying to implement. > For the Certificate Store functions I would recommend > implementing the "OID support functions" first, I was taking a look at implementing the certificate store functions, and I was thinking (hoping?) I could avoid the OID stuff. Maybe I'm missing something, but a cert will be stored in the registry in some well-known format, and as long as Wine handles the registry I/O bit, OpenSSL ought to be able to read the certs, right? So CertOpenStore/CertEnumStore et al wouldn't need to do any asn.1 decoding, at least not from the get-go. What did I miss? --Juan __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

2 3

exec-shield workaround take 3
by Mike McCormack 13 Apr '04

13 Apr '04

Hi, Here's a new patch for exec-shield. Changes against the last patch: * reserve only the area required by the PE EXE if launched from CreateProcess (else just a default slab) * pass the reserved area to wine, so wine knows about it * unmap the preloader after it is no longer used Again, comments, improvements, flames and test reports are all welcome! Mike ----------------------------------------------------------------------- Hi, This patch works around the exec-shield problems with Fedora Core. I'd be greatful if any people using Fedora core could test it out and see how it works. It should be enough to apply it to the latest CVS tip and recompile. All comments and flames accepted... /me wears his asbestos suit. Mike ChangeLog: * workaround exec-shield by reserving memory before run ld-linux.so.2 Index: dlls/kernel/process.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/process.c,v retrieving revision 1.50 diff -u -r1.50 process.c --- dlls/kernel/process.c 25 Mar 2004 23:41:04 -0000 1.50 +++ dlls/kernel/process.c 11 Apr 2004 07:14:20 -0000 @@ -1055,7 +1055,8 @@ * * Build the environment of a new child process. */ -static char **build_envp( const WCHAR *envW, const WCHAR *extra_envW ) +static char **build_envp( const WCHAR *envW, const WCHAR *extra_envW, + const char *workdir, const char *unixpath ) { const WCHAR *p; char **envp; @@ -1078,7 +1079,7 @@ if (!(env = malloc( length ))) return NULL; WideCharToMultiByte( CP_UNIXCP, 0, envW, p - envW, env, length, NULL, NULL ); - count += 4; + count += 6; if ((envp = malloc( count * sizeof(*envp) ))) { @@ -1093,6 +1094,11 @@ if ((p = getenv("TMP"))) *envptr++ = alloc_env_string( "TMP=", p ); if ((p = getenv("HOME"))) *envptr++ = alloc_env_string( "HOME=", p ); if ((p = getenv("WINEPREFIX"))) *envptr++ = alloc_env_string( "WINEPREFIX=", p ); + + /* record the unix working directory */ + if (workdir) *envptr++ = alloc_env_string( "WINEWORKDIR=", workdir ); + if (unixpath) *envptr++ = alloc_env_string( "WINEPEEXEPATH=", unixpath ); + /* now put the Windows environment strings */ for (p = env; *p; p += strlen(p) + 1) { @@ -1131,7 +1137,7 @@ if (!(pid = fork())) /* child */ { char **argv = build_argv( cmdline, 0 ); - char **envp = build_envp( env, NULL ); + char **envp = build_envp( env, NULL, NULL, NULL ); close( fd[0] ); /* Reset signals that we previously set to SIG_IGN */ @@ -1166,14 +1172,8 @@ RTL_USER_PROCESS_PARAMETERS *params; UNICODE_STRING image_str, cmdline_str, desktop, title; NTSTATUS status; - WCHAR buffer[MAX_PATH]; - - if(!GetLongPathNameW( filename, buffer, MAX_PATH )) - lstrcpynW( buffer, filename, MAX_PATH ); - if(!GetFullPathNameW( buffer, MAX_PATH, buffer, NULL )) - lstrcpynW( buffer, filename, MAX_PATH ); - RtlInitUnicodeString( &image_str, buffer ); + RtlInitUnicodeString( &image_str, filename ); RtlInitUnicodeString( &cmdline_str, cmdline ); if (startup->lpDesktop) RtlInitUnicodeString( &desktop, startup->lpDesktop ); if (startup->lpTitle) RtlInitUnicodeString( &title, startup->lpTitle ); @@ -1225,6 +1225,7 @@ pid_t pid; int err; char dummy = 0; + WCHAR buffer[MAX_PATH]; if (!env) { @@ -1232,7 +1233,12 @@ extra_env = DRIVE_BuildEnv(); } - if (!(params = create_user_params( filename, cmd_line, startup ))) + if(!GetLongPathNameW( filename, buffer, MAX_PATH )) + lstrcpynW( buffer, filename, MAX_PATH ); + if(!GetFullPathNameW( buffer, MAX_PATH, buffer, NULL )) + lstrcpynW( buffer, filename, MAX_PATH ); + + if (!(params = create_user_params( buffer, cmd_line, startup ))) { if (extra_env) HeapFree( GetProcessHeap(), 0, extra_env ); return FALSE; @@ -1263,7 +1269,20 @@ if (!(pid = fork())) /* child */ { char **argv = build_argv( cmd_line, 1 ); - char **envp = build_envp( env, extra_env ); + char **envp; + CHAR unixpath[MAX_PATH]; + + unixpath[0]=0; + wine_get_unix_file_name( buffer, unixpath, MAX_PATH ); + + /* preseve the current directory, the preloader may forget it */ + if( !unixdir ) + { + char *dir = HeapAlloc( GetProcessHeap(), 0, MAX_PATH ); + getcwd( dir, MAX_PATH ); + unixdir = dir; + } + envp = build_envp( env, extra_env, unixdir, unixpath ); close( startfd[1] ); close( execfd[0] ); @@ -1275,8 +1294,6 @@ /* Reset signals that we previously set to SIG_IGN */ signal( SIGPIPE, SIG_DFL ); signal( SIGCHLD, SIG_DFL ); - - if (unixdir) chdir(unixdir); if (argv && envp) { Index: libs/wine/config.c =================================================================== RCS file: /home/wine/wine/libs/wine/config.c,v retrieving revision 1.3 diff -u -r1.3 config.c --- libs/wine/config.c 11 Nov 2003 22:21:29 -0000 1.3 +++ libs/wine/config.c 11 Apr 2004 07:14:21 -0000 @@ -243,6 +243,23 @@ return user_name; } +/* run wine binary in it's own directory, so it can find it's preloader */ +int wine_cwd_execve( const char *name, char **argv, char **envp ) +{ + char *dir, *p; + + dir = strdup( name ); + p = strrchr( dir, '/' ); + if( p ) + { + *p++ = 0; + chdir( dir ); + name = p; + } + + return execve( name, argv, envp ); +} + /* exec a wine internal binary (either the wine loader or the wine server) */ /* if name is null, default to the name of the current binary */ void wine_exec_wine_binary( const char *name, char **argv, char **envp ) @@ -257,7 +274,7 @@ argv[0] = xmalloc( sizeof(BINDIR "/") + strlen(name) ); strcpy( argv[0], BINDIR "/" ); strcat( argv[0], name ); - execve( argv[0], argv, envp ); + wine_cwd_execve( argv[0], argv, envp ); free( argv[0] ); /* now try the path of argv0 of the current binary */ @@ -266,7 +283,7 @@ argv[0] = xmalloc( strlen(argv0_path) + strlen(name) + 1 ); strcpy( argv[0], argv0_path ); strcat( argv[0], name ); - execve( argv[0], argv, envp ); + wine_cwd_execve( argv[0], argv, envp ); free( argv[0] ); } @@ -283,7 +300,7 @@ memcpy( argv[0], pos, ptr - pos ); strcpy( argv[0] + (ptr - pos), "/" ); strcat( argv[0] + (ptr - pos), name ); - execve( argv[0], argv, envp ); + wine_cwd_execve( argv[0], argv, envp ); pos = ptr; } free( argv[0] ); Index: loader/Makefile.in =================================================================== RCS file: /home/wine/wine/loader/Makefile.in,v retrieving revision 1.14 diff -u -r1.14 Makefile.in --- loader/Makefile.in 22 Nov 2003 00:08:26 -0000 1.14 +++ loader/Makefile.in 11 Apr 2004 07:14:21 -0000 @@ -23,20 +23,30 @@ LIBPTHREAD = @LIBPTHREAD@ LDEXECFLAGS = @LDEXECFLAGS@ -wine-glibc: glibc.o Makefile.in +WINELDEXECFLAGS = $(LDEXECFLAGS),--dynamic-linker=$(WINELDSO) + +WINELDSO=ld-winepreload.so + +$(WINELDSO): preload.o Makefile.in + $(CC) -nostartfiles -lc -static -Wl,"-Ttext=0x7ff81000" -o $@ $< + +preload.c: preload.h main.h + +wine-glibc: glibc.o Makefile.in $(WINELDSO) $(CC) -o $@ $(LDEXECFLAGS) glibc.o $(LIBWINE) $(LIBPORT) $(LIBPTHREAD) $(EXTRALIBS) $(LDFLAGS) -wine-kthread: $(KTHREAD_OBJS) Makefile.in - $(CC) -o $@ $(LDEXECFLAGS) $(KTHREAD_OBJS) $(LIBWINE) $(LIBPORT) $(EXTRALIBS) $(LDFLAGS) +wine-kthread: $(KTHREAD_OBJS) Makefile.in $(WINELDSO) + $(CC) -o $@ $(WINELDEXECFLAGS) $(KTHREAD_OBJS) $(LIBWINE) $(LIBPORT) $(EXTRALIBS) $(LDFLAGS) -wine-pthread: $(PTHREAD_OBJS) Makefile.in - $(CC) -o $@ $(LDEXECFLAGS) $(PTHREAD_OBJS) $(LIBWINE) $(LIBPORT) $(LIBPTHREAD) $(EXTRALIBS) $(LDFLAGS) +wine-pthread: $(PTHREAD_OBJS) Makefile.in $(WINELDSO) + $(CC) -o $@ $(WINELDEXECFLAGS) $(PTHREAD_OBJS) $(LIBWINE) $(LIBPORT) $(LIBPTHREAD) $(EXTRALIBS) $(LDFLAGS) $(MODULE): $(MAIN_BINARY) $(RM) $(MODULE) && $(LN_S) $(MAIN_BINARY) $(MODULE) install:: $(WINE_BINARIES) $(MKINSTALLDIRS) $(bindir) + $(INSTALL_PROGRAM) $(WINELDSO) $(bindir); \ for f in $(WINE_BINARIES); do \ if [ "$(MAIN_BINARY)" = "$$f" ]; \ then $(INSTALL_PROGRAM) $$f $(bindir)/$(MODULE); \ @@ -48,6 +58,6 @@ $(RM) $(WINE_BINARIES:%=$(bindir)/%) $(bindir)/$(MODULE) clean:: - $(RM) $(WINE_BINARIES) $(MODULE) + $(RM) $(WINE_BINARIES) $(MODULE) $(WINELDSO) ### Dependencies: Index: loader/glibc.c =================================================================== RCS file: /home/wine/wine/loader/glibc.c,v retrieving revision 1.3 diff -u -r1.3 glibc.c --- loader/glibc.c 20 Feb 2004 20:19:23 -0000 1.3 +++ loader/glibc.c 11 Apr 2004 07:14:21 -0000 @@ -75,6 +75,17 @@ { const char *loader = getenv( "WINELOADER" ); const char *threads = get_threading(); + char cwd[MAX_PATH], *cwd_var; + + if( !getcwd( cwd, sizeof cwd ) ) + { + fprintf( stderr, "wine: could get current directory\n" ); + exit(1); + } + cwd_var = xmalloc( sizeof("WINEWORKDIR=") + strlen(cwd) ); + strcpy( cwd_var, "WINEWORKDIR=" ); + strcat( cwd_var, cwd ); + putenv( cwd_var ); if (loader) { @@ -86,6 +97,9 @@ new_name = xmalloc( (path - loader) + strlen(threads) + 1 ); memcpy( new_name, loader, path - loader ); + new_name[ path - loader ] = 0; + if( new_name[0] ) + chdir( new_name ); strcpy( new_name + (path - loader), threads ); /* update WINELOADER with the new name */ Index: loader/main.c =================================================================== RCS file: /home/wine/wine/loader/main.c,v retrieving revision 1.90 diff -u -r1.90 main.c --- loader/main.c 20 Jan 2004 00:28:01 -0000 1.90 +++ loader/main.c 11 Apr 2004 07:14:21 -0000 @@ -20,19 +20,44 @@ #include <stdio.h> #include <stdlib.h> +#include <unistd.h> +#include <sys/mman.h> #include "wine/library.h" +#include "main.h" + +/* this variable is set by the wine-specific shared object loader */ +struct wine_preload_info *wine_preload_vars; + /********************************************************************** * main */ int main( int argc, char *argv[] ) { - char error[1024]; + char error[1024], *dir; + + if( wine_preload_vars ) + { + /* printf("vars(*%p) = %p -> (%p, %08x) (%p, %08x)\n", + &wine_preload_vars, wine_preload_vars, + wine_preload_vars->pe_address, + wine_preload_vars->pe_size, + wine_preload_vars->preload_base, + wine_preload_vars->preload_size ); */ + + /* let wine know which area was mapped */ + wine_set_pe_load_area(wine_preload_vars->pe_address, + wine_preload_vars->pe_size); + + /* unmap the preloader itself */ + munmap( wine_preload_vars->preload_base, + wine_preload_vars->preload_size ); + wine_preload_vars = NULL; + } -#if 0 - static char pe_load[256*1024*1024] __attribute__((aligned(4096))); - wine_set_pe_load_area( pe_load, sizeof(pe_load) ); -#endif + dir = getenv( "WINEWORKDIR" ); + if( dir ) + chdir( dir ); wine_init( argc, argv, error, sizeof(error) ); fprintf( stderr, "wine: failed to initialize: %s\n", error ); --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ loader/main.h 2004-04-11 16:58:25.000000000 +0900 @@ -0,0 +1,8 @@ + +struct wine_preload_info +{ + void *pe_address; + size_t pe_size; + void *preload_base; + size_t preload_size; +}; --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ loader/preload.h 2004-04-11 16:58:25.000000000 +0900 @@ -0,0 +1,51 @@ +/* + mini loader for ld.so - x86 Linux 2.4.x+ kernels only + + Copyright 2004 Mike McCormack for Codeweavers + + Copyright (C) 1995,96,97,98,99,2000,2001,2002 Free Software Foundation, Inc. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + 02111-1307 USA. + */ + +#define LDSO_NAME "/lib/ld-linux.so.2" + +/* ELF definitions */ +#define ELF_PREFERRED_ADDRESS(loader, maplength, mapstartpref) (mapstartpref) +#define ELF_FIXED_ADDRESS(loader, mapstart) ((void) 0) + +#define __ELF_NATIVE_CLASS 32 +#define MAP_BASE_ADDR(l) 0 +#define MAP_COPY MAP_PRIVATE +#define ANONFD -1 + +#define ElfW(type) _ElfW (Elf, __ELF_NATIVE_CLASS, type) +#define _ElfW(e,w,t) _ElfW_1 (e, w, _##t) +#define _ElfW_1(e,w,t) e##w##t + +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <unistd.h> +#include <sys/mman.h> +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> + +#define GL(x) x + +extern unsigned int GL(dl_pagesize); + --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ loader/preload.c 2004-04-11 16:58:25.000000000 +0900 @@ -0,0 +1,727 @@ +/* + mini loader for ld.so - x86 Linux 2.4.x+ kernels only + + Copyright 2004 Mike McCormack for Codeweavers + + Copyright (C) 1995,96,97,98,99,2000,2001,2002 Free Software Foundation, Inc. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + 02111-1307 USA. + */ + +/* + * Design notes + * + * The goal of this program is to be a workaround for exec-shield, as used + * by the Linux kernel distributed with Fedora Core and other distros. + * + * To do this, we implement our own shared object loader that reserves memory + * that is important to Wine, and then loads the the standard shared object + * loader (ELF interpreter), usually ld-linux.so.2 + * + * This program will be invoked by linking it as the shared object loader + * using the link time flags --shared-loader=ld-winepreload.so . Since we + * are not using an absolute path, an executable using this shared object + * loader must be invoked from the directory that contains this loader. + * + * We will try to set up the stack an memory area so that the program that + * loads after us (eg. the wine binary) never knows we were here, except that + * areas of memory it needs are already magically reserved. + * + * The following memory areas are important to Wine: + * 0x00000000 - the DOS area + * 0x00400000 - the standard Win32 load address + * 0x65430000 - the shared heap + * + * If this program is used as the shared object loader. the only difference + * that the loaded programs should see is that this loader will be mapped + * into memory when it starts. + * + * Limitations: + * * using a non-absolution path for the shared object loader is not standard + */ + +/* + * References (things I consulted to understand how ELF loading works): + * + * glibc 2.3.2 elf/dl-load.c + * http://www.gnu.org/directory/glibc.html + * + * Linux 2.6.4 fs/binfmt_elf.c + * ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.4.tar.bz2 + * + * Userland exec, by <grugq(a)hcunix.net> + * http://cert.uni-stuttgart.de/archive/bugtraq/2004/01/msg00002.html + * + * The ELF specification: + * http://www.linuxbase.org/spec/booksets/LSB-Embedded/LSB-Embedded/book387.ht… + */ + +#include "preload.h" +#include "main.h" +#include <elf.h> + +/* the following headers are needed to get the definition for IMAGE_NT_HEADERS */ +#include <stdarg.h> +#include "windef.h" +#include "winbase.h" + +/* debugging */ +#undef DUMP_SEGMENTS +#undef DUMP_ARG +#undef DUMP_AUX_INFO +#undef DUMP_SYMS + +unsigned int GL(dl_pagesize) = 0x0000; +extern const unsigned char _end[]; + +struct link_map { + ElfW(Addr) l_addr; + ElfW(Dyn) *l_ld; + const ElfW(Phdr) *l_phdr; + ElfW(Addr) l_entry; + ElfW(Half) l_ldnum; + ElfW(Half) l_phnum; + ElfW(Addr) l_map_start, l_map_end; +}; + +/* + * wld_printf - just the basics + * + * %x prints a hex number + * %s prints a string + */ +void wld_sprintf(char *str, char *fmt, int *args ) +{ + char *p = fmt; + + while( *p ) + { + if( *p == '%' ) + { + p++; + if( *p == 'x' ) + { + int ch, i, x = *++args; + for(i=7; i>=0; i--) + { + ch = (x>>(i*4))&0xf; + ch += '0'; + if(ch>'9') + ch+=('A'-10-'0'); + *str++ = ch; + } + } + else if( *p == 's' ) + { + char *s = (char*)*++args; + while(*s) + *str++ = *s++; + } + else if( *p == 0 ) + break; + p++; + } + *str++ = *p++; + } + *str = 0; +} + +int wld_strlen(char *str) +{ + int n = 0; + while( str[n] ) + n++; + return n; +} + +void wld_printf(char *fmt, ... ) +{ + char buffer[100]; + int n; + + buffer[0]=0; + wld_sprintf(buffer, fmt, (int*)&fmt ); + n = wld_strlen( buffer ); + write(2, buffer, n); +} + +void wld_strncpy(char *dest, char *src, int count ) +{ + while( (*dest++ = *src++) && --count ) + ; + *dest = 0; +} + +void wld_memset( unsigned char *buf, int val, size_t len ) +{ + while( len-- ) + *buf++=val; +} + +#ifdef DUMP_AUX_INFO +/* + * Dump interesting bits of the ELF auxv_t structure that is passed + * as the 4th parameter to the _start function + */ +static void wld_dump_auxilary( ElfW(auxv_t) *av ) +{ + for ( ; av->a_type != AT_NULL; av++) + switch (av->a_type) + { + case AT_PAGESZ: + wld_printf("AT_PAGESZ = %x\n",av->a_un.a_val); + break; + case AT_PHDR: + wld_printf("AT_PHDR = %x\n",av->a_un.a_ptr); + break; + case AT_PHNUM: + wld_printf("AT_PHNUM = %x\n",av->a_un.a_val); + break; + case AT_ENTRY: + wld_printf("AT_ENTRY = %x\n",av->a_un.a_val); + break; + case AT_BASE: + wld_printf("AT_BASE = %x\n",av->a_un.a_val); + break; + } +} +#endif + +/* + * wld_set_auxilary + * + * Set a field of the auxillary structure + */ +void wld_set_auxilary( ElfW(auxv_t) *av, int type, long int val ) +{ + for ( ; av->a_type != AT_NULL; av++) + if( av->a_type == type ) + av->a_un.a_val = val; +} + +/* + * wld_get_auxilary + * + * Get a field of the auxillary structure + */ +int wld_get_auxilary( ElfW(auxv_t) *av, int type, int *val ) +{ + for ( ; av->a_type != AT_NULL; av++) + if( av->a_type == type ) + { + *val = av->a_un.a_val; + return 1; + } + return 0; +} + +/* + * wld_map_so + * + * modelled after _dl_map_object_from_fd() from glibc-2.3.1/elf/dl-load.c + * + * This function maps the segments from an ELF object, and optionally + * stores information about the mapping into the auxv_t structure. + */ +void* wld_map_so( int fd, void* buf, size_t buflen, struct link_map *l) +{ + ElfW(Ehdr) *header = buf; + ElfW(Phdr) *phdr, *ph; + /* Scan the program header table, collecting its load commands. */ + struct loadcmd + { + ElfW(Addr) mapstart, mapend, dataend, allocend; + off_t mapoff; + int prot; + } loadcmds[header->e_phnum], *c; + size_t nloadcmds = 0, maplength; + + header = buf; + phdr = (void*) (((unsigned char*)buf) + header->e_phoff); + + if( header->e_ident[0] != 0x7f && + header->e_ident[0] != 'E' && + header->e_ident[0] != 'L' && + header->e_ident[0] != 'F' ) + { + wld_printf("Not an ELF binary... don't know how to load it\n"); + return NULL; + } + + if( header->e_machine != EM_386 ) + { + wld_printf("Not an i386 ELF binary... don't know how to load it\n"); + return NULL; + } + + maplength = header->e_phnum * sizeof (ElfW(Phdr)); + if (header->e_phoff + maplength > (size_t) buflen) + { + wld_printf("oops... not enough space for ELF headers\n"); + exit(1); + } + + l->l_ld = 0; + l->l_addr = 0; + l->l_phnum = header->e_phnum; + l->l_entry = header->e_entry; + + for (ph = phdr; ph < &phdr[l->l_phnum]; ++ph) + { + +#ifdef DUMP_SEGMENTS + wld_printf( "ph = %x\n", ph ); + wld_printf( " p_type = %x\n", ph->p_type ); + wld_printf( " p_flags = %x\n", ph->p_flags ); + wld_printf( " p_offset = %x\n", ph->p_offset ); + wld_printf( " p_vaddr = %x\n", ph->p_vaddr ); + wld_printf( " p_paddr = %x\n", ph->p_paddr ); + wld_printf( " p_filesz = %x\n", ph->p_filesz ); + wld_printf( " p_memsz = %x\n", ph->p_memsz ); + wld_printf( " p_align = %x\n", ph->p_align ); +#endif + + switch (ph->p_type) + { + /* These entries tell us where to find things once the file's + segments are mapped in. We record the addresses it says + verbatim, and later correct for the run-time load address. */ + case PT_DYNAMIC: + l->l_ld = (void *) ph->p_vaddr; + l->l_ldnum = ph->p_memsz / sizeof (Elf32_Dyn); + break; + + case PT_PHDR: + l->l_phdr = (void *) ph->p_vaddr; + break; + + case PT_TLS: + /* + * We don't need to set anything up because we're + * emulating the kernel, not ld-linux.so.2 + * The ELF loader will set up the TLS data itself. + */ + break; + + case PT_LOAD: + { + if ((ph->p_align & (GL(dl_pagesize) - 1)) != 0) + { + wld_printf("ELF load command alignment not page-aligned"); + return NULL; + } + if (((ph->p_vaddr - ph->p_offset) & (ph->p_align - 1)) != 0) + { + wld_printf("ELF load command address/offset not properly aligned"); + return NULL; + } + + c = &loadcmds[nloadcmds++]; + c->mapstart = ph->p_vaddr & ~(ph->p_align - 1); + c->mapend = ((ph->p_vaddr + ph->p_filesz + GL(dl_pagesize) - 1) + & ~(GL(dl_pagesize) - 1)); + c->dataend = ph->p_vaddr + ph->p_filesz; + c->allocend = ph->p_vaddr + ph->p_memsz; + c->mapoff = ph->p_offset & ~(ph->p_align - 1); + + c->prot = 0; + if (ph->p_flags & PF_R) + c->prot |= PROT_READ; + if (ph->p_flags & PF_W) + c->prot |= PROT_WRITE; + if (ph->p_flags & PF_X) + c->prot |= PROT_EXEC; + } + break; + + case PT_INTERP: + break; + + case PT_SHLIB: + case PT_NOTE: + case PT_GNU_EH_FRAME: + case 0x6474e551: /* FIXME: what is this? */ + break; + + default: + wld_printf("warning: unknown header type %x\n", ph->p_type); + break; + } + } + + /* Now process the load commands and map segments into memory. */ + c = loadcmds; + + /* Length of the sections to be loaded. */ + maplength = loadcmds[nloadcmds - 1].allocend - c->mapstart; + + if( header->e_type == ET_DYN ) + { + ElfW(Addr) mappref; + mappref = (ELF_PREFERRED_ADDRESS (loader, maplength, c->mapstart) + - MAP_BASE_ADDR (l)); + + /* Remember which part of the address space this object uses. */ + l->l_map_start = (ElfW(Addr)) mmap ((void *) mappref, maplength, + c->prot, MAP_COPY | MAP_FILE, + fd, c->mapoff); + /* wld_printf("set : offset = %x\n", c->mapoff); */ + /* wld_printf("l->l_map_start = %x\n", l->l_map_start); */ + + l->l_map_end = l->l_map_start + maplength; + l->l_addr = l->l_map_start - c->mapstart; + + mprotect ((caddr_t) (l->l_addr + c->mapend), + loadcmds[nloadcmds - 1].allocend - c->mapend, + PROT_NONE); + goto postmap; + } + else + { + ELF_FIXED_ADDRESS (loader, c->mapstart); + } + + /* Remember which part of the address space this object uses. */ + l->l_map_start = c->mapstart + l->l_addr; + l->l_map_end = l->l_map_start + maplength; + + while (c < &loadcmds[nloadcmds]) + { + if (c->mapend > c->mapstart) + /* Map the segment contents from the file. */ + mmap ((void *) (l->l_addr + c->mapstart), + c->mapend - c->mapstart, c->prot, + MAP_FIXED | MAP_COPY | MAP_FILE, fd, c->mapoff); + + postmap: + if (l->l_phdr == 0 + && (ElfW(Off)) c->mapoff <= header->e_phoff + && ((size_t) (c->mapend - c->mapstart + c->mapoff) + >= header->e_phoff + header->e_phnum * sizeof (ElfW(Phdr)))) + /* Found the program header in this segment. */ + l->l_phdr = (void *) (c->mapstart + header->e_phoff - c->mapoff); + + if (c->allocend > c->dataend) + { + /* Extra zero pages should appear at the end of this segment, + after the data mapped from the file. */ + ElfW(Addr) zero, zeroend, zeropage; + + zero = l->l_addr + c->dataend; + zeroend = l->l_addr + c->allocend; + zeropage = ((zero + GL(dl_pagesize) - 1) + & ~(GL(dl_pagesize) - 1)); + + /* + * This is different to the dl-load load... + * ld-linux.so.2 relies on the whole page being zero'ed + */ + zeroend = (zeroend +GL(dl_pagesize) - 1) & ~(GL(dl_pagesize) - 1); + + if (zeroend < zeropage) + { + /* All the extra data is in the last page of the segment. + We can just zero it. */ + zeropage = zeroend; + } + + if (zeropage > zero) + { + /* Zero the final part of the last page of the segment. */ + if ((c->prot & PROT_WRITE) == 0) + { + /* Dag nab it. */ + mprotect ((caddr_t) (zero & ~(GL(dl_pagesize) - 1)), + GL(dl_pagesize), + c->prot|PROT_WRITE); + } + memset ((void *) zero, '\0', zeropage - zero); + if ((c->prot & PROT_WRITE) == 0) + mprotect ((caddr_t) (zero & ~(GL(dl_pagesize) - 1)), + GL(dl_pagesize), c->prot); + } + + if (zeroend > zeropage) + { + /* Map the remaining zero pages in from the zero fill FD. */ + caddr_t mapat; + mapat = mmap ((caddr_t) zeropage, zeroend - zeropage, + c->prot, MAP_ANON|MAP_PRIVATE|MAP_FIXED, + ANONFD, 0); + } + } + + ++c; + } + + if (l->l_phdr == NULL) + { + wld_printf("no program header\n"); + exit(1); + } + + (ElfW(Addr)) l->l_phdr += l->l_addr; + (ElfW(Addr)) l->l_entry += l->l_addr; + + return (void*)l->l_entry; +} + +#define ROUND_SIZE(addr,size) \ + (((int)(size) + ((int)(addr) & page_mask) + page_mask) & ~page_mask) + +/* + * wld_reserve_wine_memory + * + * This is the reason we are here. + * We want to reserve address space so that the kernel doesn't + * map stuff there. We do this by getting in first before + * anything else is mapped (except this program) and reserve + * the memory we want. + */ +void wld_reserve_wine_memory( char *pe_file, void **base, size_t *size ) +{ + IMAGE_DOS_HEADER dos; + IMAGE_NT_HEADERS nt; + int unix_fd, page_mask = GL(dl_pagesize) - 1; + + if( !pe_file ) + return; + + unix_fd = open( pe_file, O_RDONLY, 0); + if( unix_fd < 0 ) + return; + + /* + * The following code is borrowed from + * get_image_params() in wine/server/mapping.c + */ + if (read( unix_fd, &dos, sizeof(dos) ) != sizeof(dos)) goto error; + if (dos.e_magic != IMAGE_DOS_SIGNATURE) goto error; + if (lseek( unix_fd, dos.e_lfanew, SEEK_SET ) == -1) goto error; + + if (read( unix_fd, &nt.Signature, sizeof(nt.Signature) ) != sizeof(nt.Signature)) goto error; + if (nt.Signature != IMAGE_NT_SIGNATURE) goto error; + if (read( unix_fd, &nt.FileHeader, sizeof(nt.FileHeader) ) != sizeof(nt.FileHeader)) goto error; + /* zero out Optional header in the case it's not present or partial */ + memset(&nt.OptionalHeader, 0, sizeof(nt.OptionalHeader)); + if (read( unix_fd, &nt.OptionalHeader, nt.FileHeader.SizeOfOptionalHeader) != nt.FileHeader.SizeOfOptionalHeader) goto error; + + *size = ROUND_SIZE( 0, nt.OptionalHeader.SizeOfImage ); + *base = (void *)nt.OptionalHeader.ImageBase; + +#ifdef DUMP_PERESERVE + wld_printf( "parsed PE image... base %x size %x\n", *base, *size ); +#endif + +error: + close( unix_fd ); +} + +/* + * Find a symbol in the symbol table of the executable loaded + */ +void *wld_find_symbol( const ElfW(Phdr) *phdr, int num, char *var ) +{ + const ElfW(Dyn) *dyn = NULL; + void *ptr = NULL; + const ElfW(Phdr) *ph; + const ElfW(Sym) *symtab = NULL; + const char *strings = NULL; + + /* check the values */ +#ifdef DUMP_SYMS + wld_printf("%x %x\n", phdr, num ); +#endif + if( ( phdr == NULL ) || ( num == 0 ) ) + { + wld_printf("could not find PT_DYNAMIC header entry\n"); + return NULL; + } + + /* parse the (already loaded) ELF executable's header */ + for (ph = phdr; ph < &phdr[num]; ++ph) + { + if( PT_DYNAMIC == ph->p_type ) + { + dyn = (void *) ph->p_vaddr; + num = ph->p_memsz / sizeof (Elf32_Dyn); + break; + } + } + if( !dyn ) + { + wld_printf("No PT_DYNAMIC section\n"); + return ptr; + } + + while( dyn->d_tag ) + { + if( dyn->d_tag == DT_STRTAB ) + strings = (const char*) dyn->d_un.d_ptr; + if( dyn->d_tag == DT_SYMTAB ) + symtab = (const ElfW(Sym) *)dyn->d_un.d_ptr; +#ifdef DUMP_SYMS + wld_printf("%x %x\n", dyn->d_tag, dyn->d_un.d_ptr ); +#endif + dyn++; + } + + if( (!symtab) || (!strings) ) + { + wld_printf("No symbol table found\n"); + return ptr; + } + + /* FIXME: this crashes if it doesn't find the symbol we want */ + do + { + if( ( ELF32_ST_BIND(symtab->st_info) == STT_OBJECT ) && + ( 0 == strcmp( strings+symtab->st_name, var ) ) ) + { + ptr = (void*)symtab->st_value; + break; + } + symtab++; + } + while( symtab->st_name ); + +#ifdef DUMP_SYMS + wld_printf("Found %s -> %x\n", strings+symtab->st_name, symtab->st_value ); +#endif + + return ptr; +} + +/* + * wld_start + * + * Repeat the actions the kernel would do when loading a dynamically linked .so + * Load the ELF interperter ld-linux.so and then binary itself. + * + * Note, we assume that the binary is a dynamically linked ELF shared object + * and that ld-linux.so is its ELF interpreter. + */ +void* wld_start( int argc ) +{ + int fd, phnum = 0; + unsigned char buf[0x800]; + void *start; + char **argv = (char**) &argc, **p, *pe_file = NULL; + struct link_map map; + ElfW(auxv_t)* av; + ElfW(Phdr) *elf_phdr = NULL; + struct wine_preload_info **wine_preload_vars; + static struct wine_preload_info vars; + + memset( &map, 0, sizeof map ); + + /* skip over the parameters */ + p = ++argv; +#ifdef DUMP_ARG + { + int i; + for( i = 0; i<argc; i++ ) + wld_printf("argv[%x] = %s\n", i, *p++); + if(*p++) + wld_printf("argv[argc] not NULL!!\n"); + } +#else + p+=(argc+1); +#endif + + /* skip over the environment, find the name of the PE file */ + while( *p ) + { + const char pefile[] = "WINEPEEXEPATH="; + if( 0 == memcmp( pefile, *p, sizeof pefile - 1 ) ) + pe_file = (*p) + sizeof pefile - 1 ; + p++; + } + + av = (ElfW(auxv_t)*) (p+1); + wld_get_auxilary( av, AT_PAGESZ, &dl_pagesize ); +#ifdef DUMP_AUX_INFO + wld_dump_auxilary( av ); +#endif + + /* reserve memory that Wine needs */ + vars.pe_size = 0x01000000; + vars.pe_address = (void*)0x00400000; + wld_reserve_wine_memory( pe_file, &vars.pe_address, &vars.pe_size ); + mmap( vars.pe_address, vars.pe_size, PROT_NONE, + MAP_FIXED|MAP_PRIVATE|MAP_ANON, -1, 0); + + /* load the original dynamic loader itself */ + fd = open( LDSO_NAME, O_RDONLY, 0); + if( fd < 0 ) + { + wld_printf( "error: fd = %x\n", fd); + exit(1); + } + read( fd, buf, sizeof buf ); + start = wld_map_so( fd, buf, sizeof buf, &map ); + if( !start ) + exit(0); + close( fd ); + + /* + * Pass information to the wine loader in a static variable + * so it doesn't get destroyed after we leave this stack frame + */ + wld_get_auxilary( av, AT_PHDR, (int*)&elf_phdr ); + wld_get_auxilary( av, AT_PHNUM, (int*)&phnum ); + wine_preload_vars = wld_find_symbol( elf_phdr, phnum, "wine_preload_vars" ); + if( wine_preload_vars ) + { + unsigned char *base = (void*)0x7ff81000; /* FIXME - define properly */ + vars.preload_base = (void*) base; + vars.preload_size = (size_t) (_end - base); + *wine_preload_vars = &vars; + } + + wld_set_auxilary( av, AT_BASE, map.l_addr ); + +#ifdef DUMP_AUX_INFO + wld_printf("New auxillary info:\n"); + wld_dump_auxilary( av ); + wld_printf("jumping to %x\n", start); +#endif + + return start; +} + +/* + * The _start function is the entry and exit point of this program + * + * It calls wld_start, passing a pointer to the args it receives + * then jumps to the address wld_start returns after removing the + * first argv[] value, and decrementing argc + */ +void _start(void); +__asm ( + ".align 4\n" + "\t.global _start\n" + "\t.type _start,@function\n" +"_start:\n" + "\tcall wld_start\n" + "\tpush %eax\n" + "\txor %eax,%eax\n" + "\txor %ebx,%ebx\n" + "\txor %ecx,%ecx\n" + "\txor %edx,%edx\n" + "\tret\n" +); +

2 6

RE: Handling dialog messages for non-template based dialogs
by Santosh Siddheshwar 13 Apr '04

13 Apr '04

Hi, I didnt get the second point that you mention Another one might be that WM_CREATE must be always passed to DEFDLG_Proc regardless of what result an application returned to DefDlgProc16/A/W. Regards Santosh Siddheshwar > -----Original Message----- > From: Dmitry Timoshkov [SMTP:dmitry@baikal.ru] > Sent: Tuesday, April 13, 2004 5:46 PM > To: Robert Shearman; wine-devel(a)winehq.org > Cc: santosh.s(a)sonata-software.com > Subject: Re: Handling dialog messages for non-template based dialogs > > "Robert Shearman" <R.J.Shearman(a)warwick.ac.uk> wrote: > > > > + if (!(dlgInfo = HeapAlloc( GetProcessHeap(), 0, > > sizeof(*dlgInfo) ))) return 0; > > > > Minor point, but you probably want to return -1 here to say that window > > creation failed. > > Good catch. Another one might be that WM_CREATE must be always > passed to DEFDLG_Proc regardless of what result an application > returned to DefDlgProc16/A/W. > > -- > Dmitry. ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

2 1

RE: Handling dialog messages for non-template based dialogs
by Robert Shearman 13 Apr '04

13 Apr '04

Santosh Siddheshwar wrote: > > Change Log: > windows/defdlg.c - Added code for allocating DIALOGINFO structure and > storing it as an attribute of the window > windows/dialog.c - Removed code for allocating DIALOGINFO structure and > moved initialization of DIALOGINFO structure > to after CreateWindowEx has been called. > <<patch.diff>> > > diff -urN wine-20040408/windows/defdlg.c wine-bin/windows/defdlg.c > --- wine-20040408/windows/defdlg.c 2003-09-06 04:45:40.000000000 +0530 > +++ wine-bin/windows/defdlg.c 2004-04-13 11:53:02.000000000 +0530 > @@ -168,6 +168,27 @@ > { > switch(msg) > { > + case WM_CREATE: > + { > + /* Allocate memory for DIALOGINFO structure and store in DWL_DIALOGINFO > + structure. Also flag the window as a dialog type */ > + WND* wndPtr; > + DIALOGINFO* dlgInfo; > + if (!(dlgInfo = HeapAlloc( GetProcessHeap(), 0, sizeof(*dlgInfo) ))) return 0; Minor point, but you probably want to return -1 here to say that window creation failed. > + dlgInfo->hwndFocus = 0; > + dlgInfo->hUserFont = 0; > + dlgInfo->hMenu = 0; > + dlgInfo->xBaseUnit = 0; > + dlgInfo->yBaseUnit = 0; Rob

2 1

[PATCH] SHLWapi fixes - Need cleanup
by Flameeyes 13 Apr '04

13 Apr '04

Hi, Some time ago I fixed some stubs on SHLWapi lib, but the patch needs some cleanup. I haven't the time to do them (because they are not "natural" for me, and when I tried to post the cleaned up version I missed a lot of cleans. If someone can take a look at it, clean it up and possibly merge it, the patch can be downloaded from http://flameeyes.web.ctonet.it/patches/wine-shlwapi_20031219.diff . Should apply well also in the current version, because it never created conflicts with code in CVS. HTH -- Flameeyes <dgp85(a)users.sourceforge.net> http://flameeyes.web.ctonet.it/

1 0

Re: Trace flags passed to SetWindowPos for easier debugging.
by Dmitry Timoshkov 13 Apr '04

13 Apr '04

"Mike Hearn" <mh(a)codeweavers.com> wrote: > Mike Hearn <mike(a)navi.cx> > Trace flags passed to SetWindowPos for easier debugging. Did you try to add +win? Is that what you are looiking for? windows/winpos.c,1176: BOOL WINAPI SetWindowPos( HWND hwnd, HWND hwndInsertAfter, INT x, INT y, INT cx, INT cy, UINT flags ) { WINDOWPOS winpos; TRACE("hwnd %p, after %p, %d,%d (%dx%d), flags %08x\n", hwnd, hwndInsertAfter, x, y, cx, cy, flags); if(TRACE_ON(win)) dump_winpos_flags(flags); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- Dmitry.

2 1

Wine-20040408 Results (so far) for MFC App
by greensh＠knology.net 13 Apr '04

13 Apr '04

Now it works very nicely... I spent Easter debugging most of the crashes I was having due to the GUI menus (even in winders), from variables not freed, etc and now I cannot get it to crash...yet. I'm using MSVC6 for all the development under VMware 4.5.1. The GUI code is completely MFC with 16 color bitmaps for resources and all underlying solver code, etc is C++/C. This code puts a P4 laptop and memory under moderate load when run... so it's a good test. Below are the ONLY messages I get from Wine-20040408 when I run it from the command-line; wine sokoban.exe (then it opens the GUI) and then do many things with it; data file I/O, parsing many text files, GUI menus, clicks, etc. As you can see below the help file opens fine, but does not display text properly. I used Shalom Help (free) for winders (it works fine on winxp as I've tested). Any ideas why these messages appear and how to prevent them? I can send app screenshots and provide code snippets. Below these is my entire wine config. fixme:dc:LockWindowUpdate (0x10029), partial stub! fixme:dc:LockWindowUpdate ((nil)), partial stub! fixme:dc:LockWindowUpdate (0x10029), partial stub! fixme:dc:LockWindowUpdate ((nil)), partial stub! fixme:dc:LockWindowUpdate (0x10029), partial stub! fixme:dc:LockWindowUpdate ((nil)), partial stub! fixme:winhelp:HLPFILE_UncompressRLE Null length 2, next is 0 fixme:winhelp:HLPFILE_UncompressRLE Null length 2, next is 140 fixme:winhelp:HLPFILE_UncompressRLE Buffer X-flow: d(108628) instead of d(108640) fixme:dc:LockWindowUpdate (0x10029), partial stub! fixme:dc:LockWindowUpdate ((nil)), partial stub! fixme:dc:LockWindowUpdate (0x10029), partial stub! fixme:dc:LockWindowUpdate ((nil)), partial stub! fixme:dc:LockWindowUpdate (0x10029), partial stub! fixme:dc:LockWindowUpdate ((nil)), partial stub! fixme:dc:LockWindowUpdate (0x10029), partial stub! fixme:dc:LockWindowUpdate ((nil)), partial stub! ~/.wine/config: [Drive C] "Path" = "/home/greensh/.wine/c" "Type" = "hd" [Drive D] "Path" = "/mnt/cdrw" "Type" = "cdrom" ; make sure that device is correct and has proper permissions ! "Device" = "/dev/scd0" [Drive E] "Path" = "/tmp" "Type" = "hd" [Drive F] "Path" = "/home/greensh" "Type" = "hd" [Drive Z] "Path" = "/" "Type" = "hd" [wine] "Windows" = "c:\\windows" "System" = "c:\\windows\\system" "Temp" = "e:\\" "Path" = "c:\\windows;c:\\windows\\system;e:\\;e:\\test;f:\\" "Profile" = "c:\\windows\\Profiles\\Administrator" "GraphicsDriver" = "x11drv" ;"ShowDirSymlinks" = "1" ;"ShowDotFiles" = "1" "ShellLinker" = "wineshelllink" # [wineconf] [Version] ; Windows version to imitate (win95,win98,winme,nt351,nt40,win2k,winxp, win2k3,win20,win30,win31) ;"Windows" = "win98" ; DOS version to imitate ;"DOS" = "6.22" ; Be careful here, wrong DllOverrides settings have the potential ; to pretty much kill your setup. [DllOverrides] ; some dlls you may want to change "oleaut32" = "builtin, native" "ole32" = "builtin, native" "comdlg32" = "builtin, native" "shell32" = "builtin, native" "shfolder" = "builtin, native" "shlwapi" = "builtin, native" "shdocvw" = "builtin, native" "advapi32" = "builtin, native" "msvcrt" = "native, builtin" "mciavi.drv" = "native, builtin" "mcianim.drv" = "native, builtin" "msi" = "native, builtin" ; you can specify applications too ; this one will apply for all notepad.exe ;"*notepad.exe" = "native, builtin" ; this one will apply only for a particular file ;"C:\\windows\\regedit.exe" = "native, builtin" ; default for all other dlls "*" = "builtin, native" [x11drv] ; Number of colors to allocate from the system palette "AllocSystemColors" = "100" ; Use a private color map "PrivateColorMap" = "N" ; Favor correctness over speed in some graphics operations "PerfectGraphics" = "N" ; Color depth to use on multi-depth screens ;;"ScreenDepth" = "16" ; Allow the window manager to manage created windows "Managed" = "Y" ; Use a desktop window of 640x480 for Wine ;"Desktop" = "640x480" ; Use XFree86 DGA extension if present ; (make sure /dev/mem is accessible by you !) "UseDGA" = "Y" ; Use XVidMode extension if present "UseXVidMode" = "Y" ; Use XRandR extension if present "UseXRandR" = "Y" ; Use the take focus protocol "UseTakeFocus" = "Y" ; Enable DirectX mouse grab "DXGrab" = "N" ; Create the desktop window with a double-buffered visual ; (useful to play OpenGL games) "DesktopDoubleBuffered" = "N" ; Run in synchronous mode (useful for debugging X11 problems) ;;"Synchronous" = "Y" ; ; Use the Render extension to render client side fonts (default "Y") ;;"ClientSideWithRender" = "Y" ; Fallback on X core requests to render client side fonts (default "Y") ;;"ClientSideWithCore" = "Y" ; Set both of the previous two to "N" in order to force X11 server side fonts ; ; Anti-alias fonts if using the Render extension (default "Y") ;;"ClientSideAntiAliasWithRender" = "Y" ; Anti-alias fonts if using core requests fallback (default "Y") ;;"ClientSideAntiAliasWithCore" = "Y" ; [fonts] ;Read the Fonts topic in the Wine User Guide before adding aliases ;See a couple of examples for russian users below "Resolution" = "96" "Default" = "-adobe-helvetica-" "DefaultFixed" = "fixed" "DefaultSerif" = "-adobe-times-" "DefaultSansSerif" = "-adobe-helvetica-" ;; default TrueType fonts with russian koi8-r encoding ;"Default" = "-monotype-arial-*-*-*--*-*-*-*-*-*-koi8-r" ;"DefaultFixed" = "-monotype-courier new-*-*-*--*-*-*-*-*-*-koi8-r" ;"DefaultSerif" = "-monotype-times new roman-*-*-*--*-*-*-*-*-*-koi8-r" ;"DefaultSansSerif" = "-monotype-arial-*-*-*--*-*-*-*-*-*-koi8-r" ;; default cyrillic bitmap X fonts ;"Default" = "-cronyx-helvetica-" ;"DefaultFixed" = "fixed" ;"DefaultSerif" = "-cronyx-times-" ;"DefaultSansSerif" = "-cronyx-helvetica-" ; the TrueType font dirs you want to make accessible to wine [FontDirs] ;"dir1" = "/usr/X11R6/lib/X11/fonts/TrueType" ;"dir2" = "/usr/share/fonts/truetype" ;"dir3" = "/usr/X11R6/lib/X11/fonts/TT" ;"dir4" = "/usr/share/fonts/TT" [ppdev] ;; key: io-base of the emulated port ;; value : parport-device{,timeout} ;; timeout for auto closing an open device ( not yet implemented) ;"378" = "/dev/parport0" ;"278" = "/dev/parport1" ;"3bc" = "/dev/parport2" [spooler] "FILE:" = "tmp.ps" "LPT1:" = "|lpr" "LPT2:" = "|gs -sDEVICE=bj200 -sOutputFile=/tmp/fred -q -" "LPT3:" = "/dev/lp3" [ports] ;"read" = "0x779,0x379,0x280-0x2a0" ;"write" = "0x779,0x379,0x280-0x2a0" [Debug] ;"RelayExclude" = "RtlEnterCriticalSection;RtlLeaveCriticalSection" ;"RelayInclude" = "user32.CreateWindowA" ;"RelayFromExclude" = "user32;x11drv" ;"RelayFromInclude" = "sol.exe" ;"SnoopExclude" = "RtlEnterCriticalSection;RtlLeaveCriticalSection" ;"SpyExclude" = "WM_SIZE;WM_TIMER;" [registry] ;These are all booleans. Y/y/T/t/1 are true, N/n/F/f/0 are false. ;Defaults are read all, write to Home ; Where to find the global registries ;"GlobalRegistryDir" = "/etc"; ; Global registries (stored in /etc) "LoadGlobalRegistryFiles" = "Y" ; Home registries (stored in ~user/.wine/) "LoadHomeRegistryFiles" = "Y" ; Load Windows registries from the Windows directory "LoadWindowsRegistryFiles" = "Y" ; TRY to write all changes to home registries "WritetoHomeRegistryFiles" = "Y" ; Registry periodic save timeout in seconds ; "PeriodicSave" = "600" ; Save only modified keys "SaveOnlyUpdatedKeys" = "Y" [Clipboard] "ClearAllSelections" = "0" "PersistentSelection" = "1" "UsePrimary" = "0" ; List of all directories directly contain .AFM files [afmdirs] "1" = "/usr/share/ghostscript/fonts" "2" = "/usr/share/a2ps/afm" "3" = "/usr/share/enscript" "4" = "/usr/X11R6/lib/X11/fonts/Type1" [WinMM] ; Uncomment the "Drivers" line matching your sound setting. "Drivers" = "wineoss.drv" ; default for most common configurations ;"Drivers" = "winearts.drv" ; for KDE ;"Drivers" = "winealsa.drv" ; for ALSA users ;"Drivers" = "winejack.drv" ; for Jack sound server ;"Drivers" = "winenas.drv" ; for NAS sound system ;"Drivers" = "wineaudioio.drv" ; for Solaris machines ;"Drivers" = "" ; to disable sound "WaveMapper" = "msacm.drv" "MidiMapper" = "midimap.drv" [dsound] ;; HEL only: Number of waveOut fragments ahead to mix in new buffers. ;"HELmargin" = "5" ;; HEL only: Number of waveOut fragments ahead to queue to driver. ;"HELqueue" = "5" ;; Max number of fragments to prebuffer ;"SndQueueMax" = "28" ;; Min number of fragments to prebuffer ;"SndQueueMin" = "12" ;; Forces emulation mode (using wave api) ;"HardwareAcceleration" = "Emulation" ;; Sets default playback device (0 - number of devices - 1) ;"DefaultPlayback" = "0" ; use first device (/dev/dsp) ;"DefaultPlayback" = "1" ; use second device (/dev/dsp1) ;"DefaultPlayback" = "2" ; use third device (/dev/dsp2) ;; Sets default capture device (0 - number of devices - 1) ;"DefaultCapture" = "0" ; use first device (/dev/dsp) ;"DefaultCapture" = "1" ; use second device (/dev/dsp1) ;"DefaultCapture" = "2" ; use third device (/dev/dsp2) [Network] ;; Use the DNS (Unix) host name always as NetBIOS "ComputerName" (boolean, default "Y"). ;; Set to N if you need a persistent NetBIOS ComputerName that possibly differs ;; from the Unix host name. You'll need to set ComputerName in ;; HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ComputerName\ComputerNam e, too. ;"UseDnsComputerName" = "N" ;; sample AppDefaults entries ; 3 InstallShield versions who like to put their full screen window in front, ; without any chance to switch to another X11 application. ; So just catch them in a desktop window. [AppDefaults\\_INS0432._MP\\x11drv] "Desktop" = "640x480" [AppDefaults\\_INS0466._MP\\x11drv] "Desktop" = "640x480" [AppDefaults\\_INS0576._MP\\x11drv] "Desktop" = "640x480" [AppDefaults\\_INS5176._MP\\x11drv] "Desktop" = "640x480" [AppDefaults\\_INS5576._MP\\x11drv] "Desktop" = "640x480" ;[AppDefaults\\iexplore.exe\\DllOverrides] ;"shlwapi" = "native" ;"rpcrt4" = "native" ;"ole32" = "native" ;"shdocvw" = "native" ;"wininet" = "native" ;"shfolder" = "native" ;"shell32" = "native" ;"shell" = "native" ;"comctl32" = "native" ; ;[AppDefaults\\setup.exe\\x11drv] ;"Desktop" = "800x600" ; ;[AppDefaults\\sol.exe\\Version] ;"Windows" = "nt40" ; ;; Some games (Quake 2, UT) refuse to accept emulated dsound devices. ;; You can add an AppDefault entry like this for such cases. ;[AppDefaults\\pickygame.exe\\dsound] ;"EmulDriver" = "N" # [/wineconf]

3 2

Windows installer XML (WiX) released on sourceforce by Microsoft
by David.Goodenough＠DGA.co.uk 13 Apr '04

13 Apr '04

Given the problems that Wine has had with Installers, had anyone noticed that WiX has now been released by Microsoft (under the CPL license) on Sourceforge. http://seattlepi.nwsource.com/business/168652_msftnotebook12.html It seems to be accessible as http://wix.sf.net, but that redirects to a blog site on http://blogs.msdn.com/robmen/category/4625.aspx. David

1 0

Re: smb: separate files
by Alexandre Julliard 12 Apr '04

12 Apr '04

Juan Lang <juan_lang(a)yahoo.com> writes: > Alexandre, this is somewhat of a test patch in that it > doesn't "do" anything besides split files up. What > I'm hoping to do is share smb.c, and to a lesser > extent netbios.c, between netapi32 and wherever else > it's needed (currently only kernel32). smbfile.c > isn't needed by netapi32. The file stuff is going to be removed anyway, so I'm not sure there's much point in splitting the file. File I/O has to be done by the Linux kernel, we can't do it right in userspace. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Remove "Path" lines from sample config
by Vincent Béron 12 Apr '04

12 Apr '04

Le dim 11/04/2004 à 20:56, Sylvain Petreolle a écrit : > Vincent, > >Changelog: > >Remove "Path" lines from sample config. > >Setup the links for the default DOS drives in wineinstall. > >+ ln -s /mnt/fd0 ~/.wine/dosdevices/a: > >+ ln -s $CROOT ~/.wine/dosdevices/c: > >+ ln -s /cdrom ~/.wine/dosdevices/d: > The cdrom is usually more often /mnt/cdrom rather than /cdrom, isnt't it ? Having only used RedHat, I can't say for sure what it's like for other distros. I just copied what was in the sample config file. Vincent

2 1

Can't load/print with a 16 bit app, wine 20040408
by ceztko＠libero.it 12 Apr '04

12 Apr '04

I can't load a 16 bit app...The problem is correlated to the printing system: i get an "run-time Error 482: Printer Error". These are the logs: Log WINEDEBUG="warn+all" ..... warn:dosfs:DOSFS_FindUnixName L"test\\WINEPS16.dll" not found in '/home/franzo/. wine/dosdevices/e:' warn:file:CreateFileW Unable to get full filename from L"e:\\test\\WINEPS16.dll" (GLE 2) warn:dosfs:DOSFS_FindUnixName L"WINEPS16.dll" not found in '/home/franzo/.wine/d osdevices/f:' warn:file:CreateFileW Unable to get full filename from L"f:\\WINEPS16.dll" (GLE 2) warn:module:load_dll Failed to load module L"WINEPS16"; status=c0000135 err:dc:CreateDCW no driver found for L"WINEPS16" Log WINEDEBUG="psdrv" ..... trace:psdrv:PSDRV_FindPrinterInfo No 'Paper Size' for printer 'HP' trace:psdrv:PSDRV_ExtDeviceMode (Driver=(null), hwnd=(nil), devOut=(nil), Device ='HP', Port='LPT1:', devIn=(nil), Profile='(null)', Mode=0000) trace:psdrv:PSDRV_FindPrinterInfo 'HP' trace:psdrv:PSDRV_ExtDeviceMode (Driver=(null), hwnd=(nil), devOut=0x41b6ce42, D evice='HP', Port='LPT1:', devIn=(nil), Profile='(null)', Mode=0002) err:dc:CreateDCW no driver found for L"WINEPS16" In /usr/local/lib/wine/ i created this situation: -rwxr-xr-x 1 root root 1851820 Apr 12 15:47 wineps.dll.so lrwxrwxrwx 1 root root 13 Apr 12 19:52 wineps.drv.so -> wineps.dll.so lrwxrwxrwx 1 root root 13 Apr 12 17:46 wineps16.dll.so -> wineps.dll.so lrwxrwxrwx 1 root root 13 Apr 12 15:47 wineps16.drv.so -> wineps.dll.so My configuration: In the registry: [System\\CurrentControlSet\\Control\\Print\\Environments\\Windows 4.0\\Drivers\\PS Driver] 1081792881 "Configuration File"="wineps16" "Data File"="<datafile?>" "Datatype"="RAW" "Dependent Files"=str(7):"" "Driver"="wineps16" "Help File"="<helpfile?>" "Monitor"="<monitor name?>" "Version"=dword:00000400 [System\\CurrentControlSet\\Control\\Print\\Printers\\HP] 1081784615 "Attributes"=dword:00000000 "Default Devmode"=hex:48,50,00,65,20,50,6f,73,74,53,63,72,69,70,74,20,44,72,69,\ 76,65,72,00,00,00,00,00,00,00,00,00,00,0a,03,01,00,9c,00,08,00,13,6b,00,00,\ 01,00,01,00,ea,0a,6f,08,64,00,01,00,07,00,00,00,02,00,01,00,00,00,03,00,00,\ 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\ 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\ 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\ 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00 "Name"="HP" "Port"="LPT1:" "Print Processor"="WinPrint" "Printer Driver"="PS Driver" "Priority"=dword:00000000 "Start Time"=dword:00000000 "Status"=dword:00000000 "Until Time"=dword:00000000 [System\\CurrentControlSet\\Control\\Print\\Printers\\HP\\PrinterDriverData] 1081784392 "PPD File"="/usr/local/share/wine/generic.ppd" [System\\CurrentControlSet\\Control\\Print\\Printers\\HP\\PrinterDriverData\\FontSubTable] 1081784392 "Arial"="Helvetica" "Courier New"="Courier" "Helv"="Helvetica" "Times New Roman"="Times" In win.ini: [windows] device=HP,WINEPS16,LPT1: [devices] HP=WINEPS16,LPT1: [PrinterPorts] HP=WINEPS16,LPT1:,15,45 In config [spooler] "FILE:" = "tmp.ps" "LPT1:" = "|lpr" "LPT2:" = "|gs -sDEVICE=bj200 -sOutputFile=/tmp/fred -q -" "LPT3:" = "/dev/lp3" Wine version is the last: 20040408. I can provide more information if needed. Thanks! Francesco Pretto P.S.: a last time WINEDEBUG="+all" log (using gentoo ebuild wine, differently than the ones before, taked using wine source unmodified), this identify the last activity before the loading of the error pop-up: ........ trace:psdrv:PSDRV_ParsePPD INPUTSLOTS 'Tray3' Name 'Tray 3' (259) Invocation '<</ManualFeed false /MediaPosition 1>>setpagedevice' trace:psdrv:PSDRV_ParsePPD INPUTSLOTS 'Manual' Name 'Manual Feed' (260) Invocation '<</ManualFeed true /Media Position 3>>setpagedevice' trace:reg:RegQueryValueExA (0x14c,"Paper Size",(nil),(nil),0x41584b84,0x41584b9c=4) trace:reg:RegQueryInfoKeyW (0x14c,(nil),0,(nil),(nil),(nil),0x41584adc,0x41584ae0,0x41584ae4,(nil),(nil)) trace:reg:RegEnumValueW (0x14c,0,0x415b7ad8,0x41584ad4,(nil),(nil),0x415b7b00,0x41584ad8) trace:reg:RegEnumValueW (0x14c,1,0x415b7ad8,0x41584ad4,(nil),(nil),0x415b7b00,0x41584ad8) trace:reg:RegEnumValueW (0x14c,2,0x415b7ad8,0x41584ad4,(nil),(nil),0x415b7b00,0x41584ad8) trace:reg:RegEnumValueW (0x14c,3,0x415b7ad8,0x41584ad4,(nil),(nil),0x415b7b00,0x41584ad8) trace:reg:RegQueryInfoKeyW (0x14c,(nil),0,(nil),(nil),(nil),0x41584adc,0x41584ae0,0x41584ae4,(nil),(nil)) trace:reg:RegEnumValueW (0x14c,0,0x415b7ad8,0x41584ad4,(nil),(nil),0x415b7b00,0x41584ad8) trace:reg:RegEnumValueW (0x14c,1,0x415b7ad8,0x41584ad4,(nil),(nil),0x415b7b00,0x41584ad8) trace:reg:RegEnumValueW (0x14c,2,0x415b7ad8,0x41584ad4,(nil),(nil),0x415b7b00,0x41584ad8) trace:reg:RegEnumValueW (0x14c,3,0x415b7ad8,0x41584ad4,(nil),(nil),0x415b7b00,0x41584ad8) trace:reg:RegEnumValueW (0x14c,0,0x415b7ad8,0x41584ad4,(nil),0x41584ad0,0x415b7b00,0x41584ad8) trace:reg:RegEnumValueW (0x14c,1,0x415b7ad8,0x41584ad4,(nil),0x41584ad0,0x415b7b00,0x41584ad8) trace:reg:RegEnumValueW (0x14c,2,0x415b7ad8,0x41584ad4,(nil),0x41584ad0,0x415b7b00,0x41584ad8) trace:reg:RegEnumValueW (0x14c,3,0x415b7ad8,0x41584ad4,(nil),0x41584ad0,0x415b7b00,0x41584ad8) err:dc:CreateDCW no driver found for L"WINEPS16" trace:int:WIN87_fpmath (cs:eip=125f:17dc es=1207 bx=0001 ax=1207 dx=1207) trace:resource:LoadString16 inst=19e6 id=01e2 buff=41a992fe len=256 trace:resource:LoadString16 strlen = 19 trace:resource:LoadString16 'Errore di stampante' loaded ! trace:resource:LoadString16 inst=19e6 id=277b buff=41a86810 len=500 trace:resource:LoadString16 strlen = 22 trace:resource:LoadString16 'Errore di run-time '|'' loaded !

1 0

current version of "wine_adopt_thread"
by Paul Davis 12 Apr '04

12 Apr '04

I offer this for Alexandre and other's consideration and comments. This is already in use in libfst, which is in turn used by Ardour, a native linux digital audio workstation, and gAlan, a native linux modular synthesis system. There is still no proper cleanup on failure, and nothing is done if the adopted thread calls pthread_exit(). Both are simple to fix. --p ---------------------------------------------------------------------- /* * winelib code - Initializes wine as shared library * * Copyright 2004 Novell, Inc. (http://www.novell.com/) * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include <stdio.h> #include <windows.h> #include <windows/ntstatus.h> #include <setjmp.h> #include <signal.h> #include <fcntl.h> #include <wine/library.h> #include <sys/mman.h> #include <dlfcn.h> #include <limits.h> #include <errno.h> #include <string.h> #include "thread.h" #include "pthread.h" #include "server.h" #include "libwinelib.h" #include "fst.h" #include <winternl.h> typedef NTSTATUS WINAPI (*NtProtectVirtualMemory_ptr)(HANDLE, PVOID*, ULONG*, ULONG, ULONG*); typedef NTSTATUS WINAPI (*NtFreeVirtualMemory_ptr)(HANDLE, PVOID, ULONG*, ULONG); typedef NTSTATUS WINAPI (*NtAllocateVirtualMemory_ptr)(HANDLE, PVOID*, PVOID, ULONG*, ULONG, ULONG); typedef VOID WINAPI (*RtlAcquirePebLock_ptr) (VOID); typedef VOID WINAPI (*RtlReleasePebLock_ptr) (VOID); static NtProtectVirtualMemory_ptr ntprotectvm; static NtAllocateVirtualMemory_ptr ntallocatevm; static NtFreeVirtualMemory_ptr ntfreevm; static RtlAcquirePebLock_ptr acquirepeblock; static RtlReleasePebLock_ptr releasepeblock; static LIST_ENTRY tls_link_head; static PEB* peb; static HTASK16 htask16; static unsigned int (*server_call)(void*); static void (*send_fd)(int); static void (*init_thread)(int,int,void*); static jmp_buf jump; static void (*sharedwine_signal_handler)(int signal, siginfo_t*, void*) = NULL; void* initial_teb; static void setup_signal (int sig) { struct sigaction sigact; struct sigaction oldact; sigact.sa_handler = (void (*)(int)) sharedwine_signal_handler; sigact.sa_flags = SA_RESTART|SA_SIGINFO; sigact.sa_sigaction = (void (*)(int signal, siginfo_t* info, void *ptr)) sharedwine_signal_handler; sigemptyset (&sigact.sa_mask); sigaddset (&sigact.sa_mask, SIGINT); sigaddset (&sigact.sa_mask, SIGUSR2); if (sigaction (sig, &sigact, NULL)) { fst_error ("could not install signal handler for signal %d", sig); } } void redirect_signals () { setup_signal (SIGINT); setup_signal (SIGFPE); setup_signal (SIGILL); setup_signal (SIGSEGV); setup_signal (SIGABRT); setup_signal (SIGTERM); setup_signal (SIGBUS); setup_signal (SIGTRAP); } /* The per-thread signal stack size */ #ifdef __i386__ #define SIGNAL_STACK_SIZE 4096 #else #define SIGNAL_STACK_SIZE 0 /* we don't need a signal stack on non-i386 */ #endif /* from winnt.h, but hard to make it appear */ #define MEM_SYSTEM 0x80000000 /*********************************************************************** * alloc_teb (no difference from libwine, but its static there) */ static TEB *shared_alloc_teb( ULONG *size ) { TEB *teb; *size = SIGNAL_STACK_SIZE + sizeof(TEB); teb = wine_anon_mmap( NULL, *size, PROT_READ | PROT_WRITE | PROT_EXEC, 0 ); if (teb == (TEB *)-1) return NULL; if (!(teb->teb_sel = wine_ldt_alloc_fs())) { munmap( teb, *size ); return NULL; } teb->Tib.ExceptionList = (void *)~0UL; teb->Tib.StackBase = (void *)~0UL; teb->Tib.Self = &teb->Tib; teb->Peb = peb; teb->StaticUnicodeString.Buffer = teb->StaticUnicodeBuffer; teb->StaticUnicodeString.MaximumLength = sizeof(teb->StaticUnicodeBuffer); return teb; } /*********************************************************************** * free_teb (no change from libwine, but its static there) */ static inline void shared_free_teb( TEB *teb ) { ULONG size = 0; void *addr = teb; ntfreevm ( GetCurrentProcess(), &addr, &size, MEM_RELEASE ); wine_ldt_free_fs( teb->teb_sel ); munmap( teb, SIGNAL_STACK_SIZE + sizeof(TEB) ); } static int proxy_pripe_request[2]; static int proxy_pripe_status[2]; static pthread_mutex_t proxy_thread_lock; static DWORD WINAPI new_thread_proxy (LPVOID param) { int request_pipe[2]; NTSTATUS status; struct __server_request_info sri; struct new_thread_request *req = &sri.u.req.new_thread_request; int fd = -1; TEB *teb; struct wine_pthread_thread_info thread_info; ULONG size; if (pipe (proxy_pripe_request)) { fst_error ("cannot set up proxy request pipe (%s)", strerror (errno)); return -1; } if (pipe (proxy_pripe_status)) { fst_error ("cannot set up proxy reply pipe (%s)", strerror (errno)); return -1; } while (1) { /* wait for a request size to be written */ if (read (proxy_pripe_request[0], &sri, sizeof (sri)) != sizeof (sri)) { fst_error ("cannot read new thread request from proxy request pipe (%s)", strerror (errno)); return -1; } if (pipe (request_pipe) >= 0) { /* set up a new request pipe */ fcntl (request_pipe[1], F_SETFD, 1); /* set close on exec flag */ /* server_*/ send_fd (request_pipe[0]); req->request_fd = request_pipe[0]; if ((status = server_call (req)) == 0) { fd = request_pipe[1]; } else { close (request_pipe[0]); close (request_pipe[1]); } } /* create a new TEB. the "thread_info" structure seems to be the most convenient way of passing back the result. */ teb = shared_alloc_teb (&size); thread_info.stack_base = NULL; thread_info.stack_size = 0; thread_info.teb_base = teb; thread_info.teb_size = size; thread_info.teb_sel = teb->teb_sel; /* send back the result, request fd and the newly allocated TEB info */ if (write (proxy_pripe_status[1], &sri, sizeof (sri)) != sizeof (sri)) { fst_error ("cannot write request/reply back to proxy reply pipe (%s)", strerror (errno)); /* XXX free teb */ return -1; } if (write (proxy_pripe_status[1], &fd, sizeof (fd)) != sizeof (status)) { fst_error ("cannot write status back to proxy reply pipe (%s)", strerror (errno)); /* XXX free teb */ return -1; } if (write (proxy_pripe_status[1], &thread_info, sizeof (thread_info)) != sizeof (thread_info)) { fst_error ("cannot write thread info to proxy reply pipe (%s)", strerror (errno)); /* XXX free teb */ return -1; } close (request_pipe[0]); } return; } extern int wine_shared_premain (); int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpszCmdLine, int nCmdShow) { int jmpstat = 1; if (CreateThread (NULL, 0, new_thread_proxy, NULL, 0, NULL) == NULL) { fst_error ("could not create new thread proxy"); } if (wine_shared_premain ()) { jmpstat = 2; } // return to caller. longjmp (jump, jmpstat); } /* WineLoadLibrary is used by System.Windows.Forms to import the Wine dlls */ void * WineLoadLibrary(unsigned char *dll) { return(LoadLibraryA(dll)); } void * WineGetProcAddress(void *handle, unsigned char *function) { return(GetProcAddress(handle, function)); } int SharedWineInit (void (*sighandler)(int,siginfo_t*,void*)) { unsigned char Error[1024]=""; char *WineArguments[] = {"sharedapp", LIBPATH "/libfst.so", NULL}; void* stackbase; size_t stacksize; void *ntdll; void *ntso; char ntdllpath[PATH_MAX+1]; char* dlerr; sharedwine_signal_handler = sighandler; if (setjmp (jump) == 0) { wine_init (2, WineArguments, Error, sizeof (Error)); if (Error[0]!='\0') { fst_error ("Wine initialization error:%s\n", Error); return -1; } } redirect_signals (); initial_teb = NtCurrentTeb(); /* set the stack limits so that any exception handling based on tracking stack boundaries has a chance of working. */ NtCurrentTeb()->Tib.StackBase = (void*) ~0UL; NtCurrentTeb()->Tib.StackLimit = 0; putenv ("_WINE_SHAREDLIB_PATH=" DLLPATH); /* Loading this will pull in many other DLLs that would otherwise be loaded+unloaded over and over again during plugin discovery. */ if (WineLoadLibrary ("user32.dll") == NULL) { fst_error ("cannot load Windows DLL user32"); return 1; } if (WineLoadLibrary ("comdlg32.dll") == NULL) { fst_error ("cannot load Windows DLL comdlg32"); return 1; } if (WineLoadLibrary ("oleaut32.dll") == NULL) { fst_error ("cannot load Windows DLL oleaut32"); return 1; } /* set up the functions and data we need to be able to adopt threads. */ #define GET_SYMBOL(res,handle,name) if ((res = WineGetProcAddress (handle,name)) == NULL) { fst_error ("cannot find Windows function %s", name); return -1; } if ((ntdll = WineLoadLibrary( "ntdll.dll")) == NULL) { fst_error ("cannot load Windows DLL ntdll"); return 1; } GET_SYMBOL (ntallocatevm, ntdll, "NtAllocateVirtualMemory"); GET_SYMBOL (ntfreevm, ntdll, "NtFreeVirtualMemory"); GET_SYMBOL (ntprotectvm, ntdll, "NtProtectVirtualMemory"); GET_SYMBOL (acquirepeblock, ntdll, "RtlAcquirePebLock"); GET_SYMBOL (releasepeblock, ntdll, "RtlReleasePebLock"); tls_link_head = NtCurrentTeb()->TlsLinks; peb = NtCurrentTeb()->Peb; htask16 = NtCurrentTeb()->htask16; sprintf (ntdllpath, "%s/ntdll.dll.so", DLLPATH); if ((ntso = dlopen (ntdllpath, RTLD_NOW|RTLD_GLOBAL)) == NULL) { fst_error ("cannot open NT DLL (%s)", ntdllpath); return -1; } server_call = dlsym (ntso, "wine_server_call"); if ((dlerr = dlerror ()) != NULL) { fst_error ("cannot find wine_server_call (%s)", dlerr); return -1; } send_fd = dlsym (ntso, "wine_server_send_fd"); if ((dlerr = dlerror ()) != NULL) { fst_error ("cannot find wine_server_send_fd (%s)", dlerr); return -1; } init_thread = dlsym (ntso, "server_init_thread"); if ((dlerr = dlerror ()) != NULL) { fst_error ("cannot find server_init_thread (%s)", dlerr); return -1; } return 0; } /*********************************************************************** * adopt_thread - take an existing linux thread (of some kind), * make the wineserver aware of it, and set up the TEB so that * we can execute win32 functions in it. */ int wine_adopt_thread (void) { struct wine_pthread_thread_info thread_info; struct debug_info* debug_info; TEB* teb; int request_fd; int tid; stack_t altstack; void *addr; ULONG size; SERVER_START_REQ( new_thread ) { req->suspend = FALSE; req->inherit = 0; /* FIXME */ pthread_mutex_lock (&proxy_thread_lock); if (write (proxy_pripe_request[1], &__req, sizeof (__req)) != sizeof (__req) || read (proxy_pripe_status[0], &__req, sizeof (__req)) != sizeof (__req) || read (proxy_pripe_status[0], &request_fd, sizeof (request_fd)) != sizeof (request_fd) || read (proxy_pripe_status[0], &thread_info, sizeof (thread_info)) != sizeof (thread_info)) { fst_error ("cannot read/write proxy thread request (%s)", strerror (errno)); } pthread_mutex_unlock (&proxy_thread_lock); if (request_fd >= 0) { tid = reply->tid; } } SERVER_END_REQ; if (request_fd < 0) goto error; debug_info = (struct debug_info *) malloc (sizeof (struct debug_info)); debug_info->str_pos = debug_info->strings; debug_info->out_pos = debug_info->output; teb = (TEB*) thread_info.teb_base; size = thread_info.teb_size; teb->tibflags = TEBF_WIN32; teb->exit_code = STILL_ACTIVE; teb->request_fd = -1; teb->request_fd = -1; teb->reply_fd = -1; teb->wait_fd[0] = -1; teb->wait_fd[1] = -1; teb->debug_info = debug_info; teb->htask16 = htask16; wine_pthread_init_current_teb (&thread_info); teb->ClientId.UniqueProcess = (HANDLE)GetCurrentProcessId(); teb->ClientId.UniqueThread = (HANDLE)tid; teb->request_fd = request_fd; /* don't bother with signal initialization since we redirect all signals back to linux anyway. */ /* SIGNAL_Init(); */ /* server_*/ init_thread( thread_info.pid, thread_info.tid, NULL ); wine_pthread_init_thread( &thread_info ); /* create a memory view for the TEB */ ntallocatevm ( GetCurrentProcess(), &addr, teb, &size, MEM_SYSTEM, PAGE_EXECUTE_READWRITE ); /* allocate a memory view for the stack */ size = thread_info.stack_size; ntallocatevm ( GetCurrentProcess(), &teb->DeallocationStack, thread_info.stack_base, &size, MEM_SYSTEM, PAGE_EXECUTE_READWRITE ); /* limit is lower than base since the stack grows down */ teb->Tib.StackBase = (char *)thread_info.stack_base + thread_info.stack_size; teb->Tib.StackLimit = thread_info.stack_base; /* setup the guard page */ size = 1; ntprotectvm ( GetCurrentProcess(), &teb->DeallocationStack, &size, PAGE_EXECUTE_READWRITE | PAGE_GUARD, NULL ); acquirepeblock (); InsertHeadList( &tls_link_head, &teb->TlsLinks ); releasepeblock (); return 0; error: shared_free_teb (teb); /* XXX deallocate VM */ /* close thread handle */ close (request_fd); return -1; }

1 0

Winelib rookie...
by antonio serra 12 Apr '04

12 Apr '04

Hi! I'm trying to port a windows code to linux via winelib. After running winemaker I get the project files and run ./configure. At a certain point the following message appears on the console: checking for windef.h... configure: error: Could not find the Wine headers (windef.h) I have the windef.h file in a directory named /usr/include/wine/windows/. Do I need to setup any environment variables or some kind of soft links? TIA, AS __________________________________ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html

2 1

Re: Remove "Path" lines from sample config
by Ivan Leo Murray-Smith 12 Apr '04

12 Apr '04

> The cdrom is usually more often /mnt/cdrom rather than /cdrom, isnt't it ? Yes, it usually is under /mnt/, also, the floppy is /mnt/floppy under mandrake, and probably other distros. Ivan.

1 0

Re: Need to disable DTR on serial port
by Geoffrey Hausheer 12 Apr '04

12 Apr '04

On Mon, 12 Apr 2004 09:26:30 +0200, "Rein Klazes" said: > > 1) it might be better to call COMM_WhackModem() after tcsetattr() so > > previous flow control settings don't interfere with setting the RTS/DTS > > lines. > > > > 2) #ifdef guards around TIOCM_DTR and TIOCM_RTS? > > > > Agreed, I will fix this in a moment. > Well, I tried Rein's latest patch out, and it still doesn't let me communicate with the device (using either my test program or TzMax). I am not sure if the patch isn't working (I can see the relevant code being called in winedbg), if there is something else required that wine isn't doing, or if it is a timing issue. In case it is interesting, here is my test app. This appears to be the minimum set of commands needed to communicate with the device. Note the tight write/query loop. Adding even a 'Sleep(1)' within that loop prevents the communication from working in Windows. I'm open to any other suggestions. Thanks, .Geoff

1 0

RE: Handling dialog messages for non-template based dialogs
by Santosh Siddheshwar 12 Apr '04

12 Apr '04

OK. I will resend the fix after incorporating your feedback. Thanks Santosh Siddheshwar > -----Original Message----- > From: Dmitry Timoshkov [SMTP:dmitry@baikal.ru] > Sent: Monday, April 12, 2004 6:34 PM > To: Santosh Siddheshwar > Cc: wine-devel(a)winehq.com > Subject: Re: Handling dialog messages for non-template based dialogs > > "Santosh Siddheshwar" <santosh.s(a)sonata-software.com> wrote: > > > Change Log: > > windows/defdlg.c - Added code for allocating DIALOGINFO structure and > > storing it as an attribute of the window > > windows/dialog.c - Removed code for allocating DIALOGINFO structure and > > moved initialization of DIALOGINFO structure > > to after CreateWindowEx has been called. > > Very nice! I'm glad to see that you finally have fixed that. However, > I see one minor point, which needs to be addressed as well: instead > of duplicating WM_CREATE code in both DefDlgProcA and W just move it > to DEFDLG_Proc. That way you will also fix 16-bit dialog creation code > by adding the same case into DefDlgProc16. > > Thanks for your great work! > > -- > Dmitry. ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

1 0

Re: Handling dialog messages for non-template based dialogs
by Dmitry Timoshkov 12 Apr '04

12 Apr '04

"Santosh Siddheshwar" <santosh.s(a)sonata-software.com> wrote: > Change Log: > windows/defdlg.c - Added code for allocating DIALOGINFO structure and > storing it as an attribute of the window > windows/dialog.c - Removed code for allocating DIALOGINFO structure and > moved initialization of DIALOGINFO structure > to after CreateWindowEx has been called. Very nice! I'm glad to see that you finally have fixed that. However, I see one minor point, which needs to be addressed as well: instead of duplicating WM_CREATE code in both DefDlgProcA and W just move it to DEFDLG_Proc. That way you will also fix 16-bit dialog creation code by adding the same case into DefDlgProc16. Thanks for your great work! -- Dmitry.

1 0

Re: shell32: open desktop.ini to fetch icon
by Dmitry Timoshkov 12 Apr '04

12 Apr '04

"Juan Lang" <juan_lang(a)yahoo.com> wrote: > ChangeLog: if a folder contains a desktop.ini, check > it for the icon location before using the default > folder icon It would be much better if you could mark all string constants as such using 'const' key word in all your patches (including already committed, submitted and future ones). Taking into account Wine size that should considerably improve overall virtual memory usage. -- Dmitry.

1 0

Need to disable DTR on serial port
by Geoffrey Hausheer 12 Apr '04

12 Apr '04

In an ongoing effort to get TzMax working, I've been fighting to get it to talk to the device through the COM port. The problem is that the device (a wrist-watch...the program is used to download heart-rate data from said watch) is very difficult to comunicate with. In theory it is quite simple: send a 'ping' command, wait for a response, then send the 'receive' command, and read the data. In practice, getting the watch to acknowledge the initial ping is challenging. You need to repetitively send the 'ping' at odd intervals until the watch responds. Once it does, it will respond to commands readily. In any case, it turns out that one of the many requirements to get the watch to respond is to have DTR disabled (done by setting fDtrControl = DTR_CONTROL_DISABLE). But apparently the default for linux is DTR_CONTROL_ENABLE, and Wine will ignore any requests to change it (DTR_CONTROL_HANDSHAKE being unimplemented as well) I assume that driving the DTR line low is the trigger that tells the watch to listen to the Rx line. I am not sure if this is a Wine or Linux limitation, (as I have very limited knowledge of serial protocols), so I was wondering if anyone had any ideas for a suibtable workaround? Thanks, .Geoff

3 4

None
by None 12 Apr '04

12 Apr '04

by Pony.ns.zel.ru with ESMTP id i38KgMrt059607 for <wine-devel(a)winehq.org.KAV>; Fri, 9 Apr 2004 00:42:22 +0400 (MSD) (envelope-from deepfire(a)sic-elvis.zel.ru) Received: from mailserver sic-elvis by Pony.ns.zel.ru with ESMTP id i38KgMrt059598 for <wine-devel(a)winehq.org>; Fri, 9 Apr 2004 00:42:22 +0400 (MSD) (envelope-from deepfire(a)sic-elvis.zel.ru) Date: Thu, 08 Apr 2004 23:43:44 +0400 Message-ID: <87wu4qdzm7.wl(a)canopus.ns.zel.ru> From: Samium Gromoff <deepfire(a)sic-elvis.zel.ru> To: wine-devel(a)winehq.org Subject: Re: ANNOUNCE: CVS to arch gateway User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: wine-devel-admin(a)winehq.org Errors-To: wine-devel-admin(a)winehq.org X-BeenThere: wine-devel(a)winehq.org X-Mailman-Version: 2.0.13 Precedence: bulk List-Unsubscribe: <http://www.winehq.org/mailman/listinfo/wine-devel>, <mailto:wine-devel-request@winehq.org?subject=unsubscribe> List-Id: Wine Developer's List <wine-devel.winehq.org> List-Post: <mailto:wine-devel@winehq.org> List-Help: <mailto:wine-devel-request@winehq.org?subject=help> List-Subscribe: <http://www.winehq.org/mailman/listinfo/wine-devel>, <mailto:wine-devel-request@winehq.org?subject=subscribe> List-Archive: <http://www.winehq.org/hypermail/wine-devel/> Perphaps it might be interesting, that there exists a gtk2 frontend to tla, called tlator. Well, it might sound like a shameless plug, because that`s me who actually wrote it, but the perphaps the main incentive behind this mail is to widen arch acceptance among people, so who knows... ;-) The tlator arch repository is located at James Blackwell`s sourcecontrol crossroad-like place: http://sourcecontrol.net/~sgromoff/%{archives}/deepfire@betelheise.deep.net… regards, Samium Gromoff

1 0

Re: win32 build error log
by Ivan Leo Murray-Smith 11 Apr '04

11 Apr '04

> Patch is in Wine CVS. w32 packages are built against the release source, not the CVS. These fixes will affect next months build. > Patch is in MinGW CVS. Will this be ready for next month, or should I install mingw from CVS? Ivan.

1 0

Wine menu woes
by Geoffrey Hausheer 11 Apr '04

11 Apr '04

I have an application that seems to work very well, except that the menus don't work (in wine, they are fine in Windows) The app is located here (free download): http://www.acumeninc.com/download/tzmax50v3.21.exe After some debugging, I found that the app creates a menu, then destroys it and recreates it using different titles. Something like: hMenu = CreateMenu(); hSub1 = CreatePopupMenu(); ... hSub2 = CreatePopupMenu(); ... AppendMenu(hMenu, MF_STRING | MF_POPUP, hSub1, "&File"); AppendMenu(hMenu, MF_STRING | MF_POPUP, hSub2, "&Other"); ... SetMenu(hWnd,hMenu); while(GetMenuItemCount(hMenu)) RemoveMenu(hMenu,0, 0x400); //Note: this just detaches the menus hOldMenu = hMenu; DestroyMenu(hMenu); hMenu=CreateMenu(); AppendMenu(hMenu, MF_STRING | MF_POPUP, hSub1, "[&File]"); AppendMenu(hMenu, MF_STRING | MF_POPUP, hSub2, "[&Other]"); if(hMenu != hOldMenu) SetMenu(hWnd, hMenu); That last line is where wine and Windows differ. In windows, the menuid is always different, so hMenu never equals hOldMenu. In wine, we reuse the menuid, so hMenu always equals hOldMenu. Since SetMenu didn't get called after the last createMenu, the menus don't work. I have no idea why the app implements its menus this way, but I removed the 'USER_HEAP_FREE( hMenu );' in DestroyMenu() and the menus work fine, as expected (obviously this isn't a fix, just a validation that the code behaves this way). I've included a test app that does the above if anyone is interested. As a secondary issue, for some reason the 'Exit' item executes the ID_DO_SOMETHING code instead of the ID_FILE_EXIT code. It doesn't do that in windows (it correctly exits instead). I don't think it is related, and i haven't looked into it, but I thought I'd mention it. Thanks, .Geoff

4 3

Re: win32 build error log
by Filip Navara 11 Apr '04

11 Apr '04

>> i586-mingw32msvc/bin/ld: cannot find -ldxerr9 > > MinGW lacks up to date DirectX headers and import libs > but Filip Navara has been working on this. His work just > needs to be integrated into MinGW. Meanwhile I will add > a dxerr8 and dxerr9 to my MinGW rpm packages so we have > a means of cross compiling our tests. My work was recently merged into MinGW CVS. [Danny Smith immediately did some changes in dxerr libraries that I think aren't right, but haven't tested it. So it's possible that the versions in MinGW CVS will not work anyway.] - Filip

1 0

win32 build error log
by Ivan Leo Murray-Smith 11 Apr '04

11 Apr '04

The error log from the win32 build of wine-20040408 Ivan.

2 1

Re: exec-shield workaround take 2
by Dan Kegel 11 Apr '04

11 Apr '04

Mike Hearn wrote: > It seems it's turned from being an normal (albiet static) app which > reserves the areas needed then boots wine, into a reimplementation of > ld-linux.so? This isn't all bad. Consider: we could add the ability to load PE executables and shared libraries into this private ld-linux.so. At that point, the need for winelib executables to be shared libraries goes away, doesn't it? And that would make everybody very, very happy, as it would solve the problem that made mono and everybody else fork wine just so they could load Windows DLLs into native linux apps. Or am I confused? Wouldn't be the first time... - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

2 1

programs/winecfg/main.c breakage
by Gerald Pfeifer 11 Apr '04

11 Apr '04

I'm afraid the following change to programs/winecfg/main.c date: 2004/03/16 01:32:36; author: julliard; state: Exp; lines: +2 -0 Need to include config.h. broke FreeBSD (and others): /sw/gcc-3.3.2/bin/gcc -c -I. -I. -I../../include -I../../include -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o main.o main.c In file included from main.c:35: /usr/include/unistd.h:189: error: conflicting types for `select' ../../include/winsock.h:975: error: previous declaration of `select' Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

1 1

Abi Word ported to Winelib!
by Dimitrie O. Paun 11 Apr '04

11 Apr '04

Hi folks, In the past couple days I've entertained myself with porting Abi Word to Winelib. This was possible because now Abi Word has a nice MinGW build system. A total of 5 trivial patches were indeed needed for Wine: http://www.winehq.org/hypermail/wine-patches/2004/04/0122.html http://www.winehq.org/hypermail/wine-patches/2004/04/0123.html http://www.winehq.org/hypermail/wine-patches/2004/04/0124.html http://www.winehq.org/hypermail/wine-patches/2004/04/0147.html http://www.winehq.org/hypermail/wine-patches/2004/04/0155.html Notice how little we had to fix! To encourage others to port stuff to Winelib, I'll inline the hacks I did to port Abi Word. These we'll need to be cleaned up for integration into the Abi Word tree, but again, please note how little we had to change. (I've also attached a screeshot of the resulting Abi Word in action). diff -ru abiword-2.0.6/abi/src/config/platforms/mingw32.mk abiword-2.0.6-dimi/abi/src/config/platforms/mingw32.mk --- abiword-2.0.6/abi/src/config/platforms/mingw32.mk 2003-04-22 12:03:54.000000000 -0400 +++ abiword-2.0.6-dimi/abi/src/config/platforms/mingw32.mk 2004-04-09 19:50:33.000000000 -0400 @@ -28,7 +28,7 @@ ## PLATFORM_FLAGS = PORT_FLAGS = -OS_CFLAGS = -mwindows -DDM_SPECVERSION=0x0320 +OS_CFLAGS = -mno-cygwin -mwindows -DDM_SPECVERSION=0x0320 # Earnie Boyd has added DM_SPECVERSION macro (of this value) to MinGW # CVS tree on 04/14/03 so this is only for versions 2.0.0-3 and earlier ## @@ -49,8 +49,8 @@ IA64_ARCH_FLAGS = # Define tools -CC = gcc -CCC = g++ +CC = winegcc +CCC = wineg++ RANLIB = ranlib # Suffixes @@ -155,10 +155,10 @@ ABI_REQUIRE_PEER_ICONV = 1 # Define tools - resource compiler -RC = windres +RC = wrc # Suffixes -EXE_SUFFIX = .exe +#EXE_SUFFIX = .exe # Compiler flags # requires the commctrl.dll from ie4.0 or greater diff -ru abiword-2.0.6/abi/src/wp/ap/win/ap_Win32App.cpp abiword-2.0.6-dimi/abi/src/wp/ap/win/ap_Win32App.cpp --- abiword-2.0.6/abi/src/wp/ap/win/ap_Win32App.cpp 2004-01-17 07:33:11.000000000 -0500 +++ abiword-2.0.6-dimi/abi/src/wp/ap/win/ap_Win32App.cpp 2004-04-09 20:55:03.000000000 -0400 @@ -35,7 +35,6 @@ #include <string.h> #include <io.h> #include <fcntl.h> -#include <iostream.h> #include <ole2.h> #include "ut_debugmsg.h" @@ -1296,7 +1295,7 @@ // -#if !defined(__MINGW32__) && !defined(DEBUG) +#if defined(WIN32) && !defined(__MWERKS__) && !defined(__WINE__) __try #endif { @@ -1364,7 +1363,7 @@ // If an exception happens, with "catch" the block // and then the save it into disk // -#if !defined(__MINGW32__) && !defined(DEBUG) +#if defined(WIN32) && !defined(__MWERKS__) && !defined(__WINE__) __except (1) { AP_Win32App *pApp = (AP_Win32App *) XAP_App::getApp(); diff -ru abiword-2.0.6/abi/src/wp/main/win/Makefile abiword-2.0.6-dimi/abi/src/wp/main/win/Makefile --- abiword-2.0.6/abi/src/wp/main/win/Makefile 2003-07-23 23:31:36.000000000 -0400 +++ abiword-2.0.6-dimi/abi/src/wp/main/win/Makefile 2004-04-09 18:18:39.000000000 -0400 @@ -91,10 +91,10 @@ ifeq ($(OS_NAME), MINGW32) $(PROGRAM): $(OBJS) $(EXTRA_LIBDEP) @$(MAKE_OBJDIR) - @echo Linking dynamic $(PROGRAM) - $(CCC) -o $(BINDIR)/libAbiWord.dll $(SHARED_LDFLAGS) $(CFLAGS) $(OBJDIR)/dummy.o $(LDFLAGS) $(EXTRA_LIBS) $(OS_LIBS) $(XLDFLAGS) - @mv libAbiWord.dll.a $(LIBDIR) - $(CCC) -o $@ $(CFLAGS) $(OBJDIR)/Win32Main.o $(OBJDIR)/Win32Mainrc.o $(LDFLAGS) -L$(LIBDIR) -lAbiWord.dll $(OS_LIBS) $(XLDFLAGS) + #@echo Linking dynamic $(PROGRAM) + #$(CCC) -o $(BINDIR)/libAbiWord.dll $(SHARED_LDFLAGS) $(CFLAGS) $(OBJDIR)/dummy.o $(LDFLAGS) $(EXTRA_LIBS) $(OS_LIBS) $(XLDFLAGS) + #@mv libAbiWord.dll.a $(LIBDIR) + $(CCC) -o $@ $(CFLAGS) $(OBJDIR)/Win32Main.o $(OBJDIR)/Win32Mainrc.o $(LDFLAGS) $(OBJDIR)/dummy.o $(EXTRA_LIBS) $(OS_LIBS) $(XLDFLAGS) else $(PROGRAM): $(OBJS) $(EXTRA_LIBDEP) @$(MAKE_OBJDIR) diff -ru abiword-2.0.6/wv/config.h.in abiword-2.0.6-dimi/wv/config.h.in --- abiword-2.0.6/wv/config.h.in 2003-06-21 11:58:55.000000000 -0400 +++ abiword-2.0.6-dimi/wv/config.h.in 2004-04-08 00:25:53.000000000 -0400 @@ -164,7 +164,7 @@ #endif /* redefs of things that are either in glibc or we have to include them ourselves */ -#if defined(WIN32) && !defined(__MWERKS__) +#if defined(WIN32) && !defined(__MWERKS__) && !defined(__WINE__) #define strcasecmp(s1,s2) stricmp(s1,s2) #else #if !defined(__GLIBC__) || (__GLIBC__ < 2) || (__GLIBC__ == 2 && __GLIBC_MINOR__ < 2) diff -ru abiword-2.0.6/wv/config.h.msvc abiword-2.0.6-dimi/wv/config.h.msvc --- abiword-2.0.6/wv/config.h.msvc 2002-11-10 21:00:49.000000000 -0500 +++ abiword-2.0.6-dimi/wv/config.h.msvc 2004-04-08 00:23:58.000000000 -0400 @@ -169,7 +169,7 @@ #endif /* redefs of things that are either in glibc or we have to include them ourselves */ -#if defined(WIN32) && !defined(__MWERKS__) +#if defined(WIN32) && !defined(__MWERKS__) && !defined(__WINE__) #define strcasecmp(s1,s2) stricmp(s1,s2) #else #if !defined(__GLIBC__) || (__GLIBC__ < 2) || (__GLIBC__ == 2 && __GLIBC_MINOR__ < 2) diff -ru abiword-2.0.6/wv/configure.ac abiword-2.0.6-dimi/wv/configure.ac --- abiword-2.0.6/wv/configure.ac 2003-09-15 06:03:44.000000000 -0400 +++ abiword-2.0.6-dimi/wv/configure.ac 2004-04-08 00:21:32.000000000 -0400 @@ -701,7 +701,7 @@ #endif -- Dimi.

2 2

exec-shield workaround take 2
by Mike McCormack 11 Apr '04

11 Apr '04

Hi, This patch works around the exec-shield problems with Fedora Core. I'd be greatful if any people using Fedora core could test it out and see how it works. It should be enough to apply it to the latest CVS tip and recompile. All comments and flames accepted... /me wears his asbestos suit. Mike ChangeLog: * workaround exec-shield by reserving memory before run ld-linux.so.2 Index: dlls/kernel/process.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/process.c,v retrieving revision 1.50 diff -u -r1.50 process.c --- dlls/kernel/process.c 25 Mar 2004 23:41:04 -0000 1.50 +++ dlls/kernel/process.c 10 Apr 2004 12:01:01 -0000 @@ -1055,7 +1055,8 @@ * * Build the environment of a new child process. */ -static char **build_envp( const WCHAR *envW, const WCHAR *extra_envW ) +static char **build_envp( const WCHAR *envW, const WCHAR *extra_envW, + const char *workdir ) { const WCHAR *p; char **envp; @@ -1078,7 +1079,7 @@ if (!(env = malloc( length ))) return NULL; WideCharToMultiByte( CP_UNIXCP, 0, envW, p - envW, env, length, NULL, NULL ); - count += 4; + count += 5; if ((envp = malloc( count * sizeof(*envp) ))) { @@ -1093,6 +1094,10 @@ if ((p = getenv("TMP"))) *envptr++ = alloc_env_string( "TMP=", p ); if ((p = getenv("HOME"))) *envptr++ = alloc_env_string( "HOME=", p ); if ((p = getenv("WINEPREFIX"))) *envptr++ = alloc_env_string( "WINEPREFIX=", p ); + + /* record the unix working directory */ + if (workdir) *envptr++ = alloc_env_string( "WINEWORKDIR=", workdir ); + /* now put the Windows environment strings */ for (p = env; *p; p += strlen(p) + 1) { @@ -1131,7 +1136,7 @@ if (!(pid = fork())) /* child */ { char **argv = build_argv( cmdline, 0 ); - char **envp = build_envp( env, NULL ); + char **envp = build_envp( env, NULL, NULL ); close( fd[0] ); /* Reset signals that we previously set to SIG_IGN */ @@ -1263,7 +1268,16 @@ if (!(pid = fork())) /* child */ { char **argv = build_argv( cmd_line, 1 ); - char **envp = build_envp( env, extra_env ); + char **envp; + + /* preseve the current directory, the preloader may forget it */ + if( !unixdir ) + { + char *dir = HeapAlloc( GetProcessHeap(), 0, MAX_PATH ); + getcwd( dir, MAX_PATH ); + unixdir = dir; + } + envp = build_envp( env, extra_env, unixdir ); close( startfd[1] ); close( execfd[0] ); @@ -1275,8 +1289,6 @@ /* Reset signals that we previously set to SIG_IGN */ signal( SIGPIPE, SIG_DFL ); signal( SIGCHLD, SIG_DFL ); - - if (unixdir) chdir(unixdir); if (argv && envp) { Index: libs/wine/config.c =================================================================== RCS file: /home/wine/wine/libs/wine/config.c,v retrieving revision 1.3 diff -u -r1.3 config.c --- libs/wine/config.c 11 Nov 2003 22:21:29 -0000 1.3 +++ libs/wine/config.c 10 Apr 2004 12:01:01 -0000 @@ -243,6 +243,23 @@ return user_name; } +/* run wine binary in it's own directory, so it can find it's preloader */ +int wine_cwd_execve( const char *name, char **argv, char **envp ) +{ + char *dir, *p; + + dir = strdup( name ); + p = strrchr( dir, '/' ); + if( p ) + { + *p++ = 0; + chdir( dir ); + name = p; + } + + return execve( name, argv, envp ); +} + /* exec a wine internal binary (either the wine loader or the wine server) */ /* if name is null, default to the name of the current binary */ void wine_exec_wine_binary( const char *name, char **argv, char **envp ) @@ -257,7 +274,7 @@ argv[0] = xmalloc( sizeof(BINDIR "/") + strlen(name) ); strcpy( argv[0], BINDIR "/" ); strcat( argv[0], name ); - execve( argv[0], argv, envp ); + wine_cwd_execve( argv[0], argv, envp ); free( argv[0] ); /* now try the path of argv0 of the current binary */ @@ -266,7 +283,7 @@ argv[0] = xmalloc( strlen(argv0_path) + strlen(name) + 1 ); strcpy( argv[0], argv0_path ); strcat( argv[0], name ); - execve( argv[0], argv, envp ); + wine_cwd_execve( argv[0], argv, envp ); free( argv[0] ); } @@ -283,7 +300,7 @@ memcpy( argv[0], pos, ptr - pos ); strcpy( argv[0] + (ptr - pos), "/" ); strcat( argv[0] + (ptr - pos), name ); - execve( argv[0], argv, envp ); + wine_cwd_execve( argv[0], argv, envp ); pos = ptr; } free( argv[0] ); Index: loader/Makefile.in =================================================================== RCS file: /home/wine/wine/loader/Makefile.in,v retrieving revision 1.14 diff -u -r1.14 Makefile.in --- loader/Makefile.in 22 Nov 2003 00:08:26 -0000 1.14 +++ loader/Makefile.in 10 Apr 2004 12:01:01 -0000 @@ -23,20 +23,30 @@ LIBPTHREAD = @LIBPTHREAD@ LDEXECFLAGS = @LDEXECFLAGS@ -wine-glibc: glibc.o Makefile.in +WINELDEXECFLAGS = $(LDEXECFLAGS),--dynamic-linker=$(WINELDSO) + +WINELDSO=ld-winepreload.so + +$(WINELDSO): preload.o Makefile.in + $(CC) -nostartfiles -lc -static -Wl,"-Ttext=0x7ff81000" -o $@ $< + +preload.c: preload.h + +wine-glibc: glibc.o Makefile.in $(WINELDSO) $(CC) -o $@ $(LDEXECFLAGS) glibc.o $(LIBWINE) $(LIBPORT) $(LIBPTHREAD) $(EXTRALIBS) $(LDFLAGS) -wine-kthread: $(KTHREAD_OBJS) Makefile.in - $(CC) -o $@ $(LDEXECFLAGS) $(KTHREAD_OBJS) $(LIBWINE) $(LIBPORT) $(EXTRALIBS) $(LDFLAGS) +wine-kthread: $(KTHREAD_OBJS) Makefile.in $(WINELDSO) + $(CC) -o $@ $(WINELDEXECFLAGS) $(KTHREAD_OBJS) $(LIBWINE) $(LIBPORT) $(EXTRALIBS) $(LDFLAGS) -wine-pthread: $(PTHREAD_OBJS) Makefile.in - $(CC) -o $@ $(LDEXECFLAGS) $(PTHREAD_OBJS) $(LIBWINE) $(LIBPORT) $(LIBPTHREAD) $(EXTRALIBS) $(LDFLAGS) +wine-pthread: $(PTHREAD_OBJS) Makefile.in $(WINELDSO) + $(CC) -o $@ $(WINELDEXECFLAGS) $(PTHREAD_OBJS) $(LIBWINE) $(LIBPORT) $(LIBPTHREAD) $(EXTRALIBS) $(LDFLAGS) $(MODULE): $(MAIN_BINARY) $(RM) $(MODULE) && $(LN_S) $(MAIN_BINARY) $(MODULE) install:: $(WINE_BINARIES) $(MKINSTALLDIRS) $(bindir) + $(INSTALL_PROGRAM) $(WINELDSO) $(bindir); \ for f in $(WINE_BINARIES); do \ if [ "$(MAIN_BINARY)" = "$$f" ]; \ then $(INSTALL_PROGRAM) $$f $(bindir)/$(MODULE); \ @@ -48,6 +58,6 @@ $(RM) $(WINE_BINARIES:%=$(bindir)/%) $(bindir)/$(MODULE) clean:: - $(RM) $(WINE_BINARIES) $(MODULE) + $(RM) $(WINE_BINARIES) $(MODULE) $(WINELDSO) ### Dependencies: Index: loader/glibc.c =================================================================== RCS file: /home/wine/wine/loader/glibc.c,v retrieving revision 1.3 diff -u -r1.3 glibc.c --- loader/glibc.c 20 Feb 2004 20:19:23 -0000 1.3 +++ loader/glibc.c 10 Apr 2004 12:01:01 -0000 @@ -75,6 +75,17 @@ { const char *loader = getenv( "WINELOADER" ); const char *threads = get_threading(); + char cwd[MAX_PATH], *cwd_var; + + if( !getcwd( cwd, sizeof cwd ) ) + { + fprintf( stderr, "wine: could get current directory\n" ); + exit(1); + } + cwd_var = xmalloc( sizeof("WINEWORKDIR=") + strlen(cwd) ); + strcpy( cwd_var, "WINEWORKDIR=" ); + strcat( cwd_var, cwd ); + putenv( cwd_var ); if (loader) { @@ -86,6 +97,9 @@ new_name = xmalloc( (path - loader) + strlen(threads) + 1 ); memcpy( new_name, loader, path - loader ); + new_name[ path - loader ] = 0; + if( new_name[0] ) + chdir( new_name ); strcpy( new_name + (path - loader), threads ); /* update WINELOADER with the new name */ Index: loader/main.c =================================================================== RCS file: /home/wine/wine/loader/main.c,v retrieving revision 1.90 diff -u -r1.90 main.c --- loader/main.c 20 Jan 2004 00:28:01 -0000 1.90 +++ loader/main.c 10 Apr 2004 12:01:01 -0000 @@ -20,6 +20,7 @@ #include <stdio.h> #include <stdlib.h> +#include <unistd.h> #include "wine/library.h" /********************************************************************** @@ -27,12 +28,13 @@ */ int main( int argc, char *argv[] ) { - char error[1024]; + char error[1024], *dir; -#if 0 - static char pe_load[256*1024*1024] __attribute__((aligned(4096))); - wine_set_pe_load_area( pe_load, sizeof(pe_load) ); -#endif + wine_set_pe_load_area((void*)0x00400000, 0x01000000); + + dir = getenv( "WINEWORKDIR" ); + if( dir ) + chdir( dir ); wine_init( argc, argv, error, sizeof(error) ); fprintf( stderr, "wine: failed to initialize: %s\n", error ); --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ loader/preload.c 2004-04-10 21:43:23.000000000 +0900 @@ -0,0 +1,570 @@ +/* + mini loader for ld.so - x86 Linux 2.4.x+ kernels only + + Copyright 2004 Mike McCormack for Codeweavers + + Copyright (C) 1995,96,97,98,99,2000,2001,2002 Free Software Foundation, Inc. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + 02111-1307 USA. + */ + +/* + * Design notes + * + * The goal of this program is to be a workaround for exec-shield, as used + * by the Linux kernel distributed with Fedora Core and other distros. + * + * To do this, we implement our own shared object loader that reserves memory + * that is important to Wine, and then loads the the standard shared object + * loader (ELF interpreter), usually ld-linux.so.2 + * + * As Wine is i386 specific, we are not too worried about portability issues, + * but will do our best to keep the system dependencies (syscalls) seperate to + * the rest (ELF loader and printf) part of the program. + * + * This program will be invoked as follows: + * + * wld <full path to ELF executable to be loaded> <args...> + * + * We will try to set up the stack an memory area so that the program that + * loads after us (eg. the wine binary) never knows we were here, except that + * areas of memory it needs are already magically reserved. + * + * The following memory areas are important to Wine: + * 0x00000000 - the DOS area + * 0x00400000 - the standard Win32 load address + * 0x65430000 - the shared heap at + * + * There are a few things that will be different after this program passes + * control of execution to the loaded binary: + * 1) The _ variable in the environment (will be the name of this exe) + * 2) The brk area returned by brk(2) + * 3) This program will still be mapped into memory. + * 4) The command line kept by the kernel in kernel memory (/proc/self/cmdline) + * + */ + +/* + * References (things I consulted to understand how ELF loading works): + * + * glibc 2.3.2 elf/dl-load.c + * http://www.gnu.org/directory/glibc.html + * + * Linux 2.6.4 fs/binfmt_elf.c + * ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.4.tar.bz2 + * + * Userland exec, by <grugq(a)hcunix.net> + * http://cert.uni-stuttgart.de/archive/bugtraq/2004/01/msg00002.html + * + * The ELF specification: + * http://www.linuxbase.org/spec/booksets/LSB-Embedded/LSB-Embedded/book387.ht… + */ + +#include "preload.h" +#include <elf.h> + +/* debugging */ +#undef DUMP_SEGMENTS +#undef DUMP_ARG +#undef DUMP_AUX_INFO + +unsigned int GL(dl_pagesize) = 0x0000; + +struct link_map { + ElfW(Addr) l_addr; + ElfW(Dyn) *l_ld; + const ElfW(Phdr) *l_phdr; + ElfW(Addr) l_entry; + ElfW(Half) l_ldnum; + ElfW(Half) l_phnum; + ElfW(Addr) l_map_start, l_map_end; +}; + +/* + * wld_printf - just the basics + * + * %x prints a hex number + * %s prints a string + */ +void wld_sprintf(char *str, char *fmt, int *args ) +{ + char *p = fmt; + + while( *p ) + { + if( *p == '%' ) + { + p++; + if( *p == 'x' ) + { + int ch, i, x = *++args; + for(i=7; i>=0; i--) + { + ch = (x>>(i*4))&0xf; + ch += '0'; + if(ch>'9') + ch+=('A'-10-'0'); + *str++ = ch; + } + } + else if( *p == 's' ) + { + char *s = (char*)*++args; + while(*s) + *str++ = *s++; + } + else if( *p == 0 ) + break; + p++; + } + *str++ = *p++; + } + *str = 0; +} + +int wld_strlen(char *str) +{ + int n = 0; + while( str[n] ) + n++; + return n; +} + +void wld_printf(char *fmt, ... ) +{ + char buffer[100]; + int n; + + buffer[0]=0; + wld_sprintf(buffer, fmt, (int*)&fmt ); + n = wld_strlen( buffer ); + write(2, buffer, n); +} + +void wld_strncpy(char *dest, char *src, int count ) +{ + while( (*dest++ = *src++) && --count ) + ; + *dest = 0; +} + +void wld_memset( unsigned char *buf, int val, size_t len ) +{ + while( len-- ) + *buf++=val; +} + +/* + * Dump interesting bits of the ELF auxv_t structure that is passed + * as the 4th parameter to the _start function + */ +void wld_dump_auxilary( ElfW(auxv_t) *av ) +{ + for ( ; av->a_type != AT_NULL; av++) + switch (av->a_type) + { + case AT_PAGESZ: + GL(dl_pagesize) = av->a_un.a_val; +#ifndef DUMP_AUX_INFO + break; +#else + wld_printf("AT_PAGESZ = %x\n",av->a_un.a_val); + break; + case AT_PHDR: + wld_printf("AT_PHDR = %x\n",av->a_un.a_ptr); + break; + case AT_PHNUM: + wld_printf("AT_PHNUM = %x\n",av->a_un.a_val); + break; + case AT_ENTRY: + wld_printf("AT_ENTRY = %x\n",av->a_un.a_val); + break; + case AT_BASE: + wld_printf("AT_BASE = %x\n",av->a_un.a_val); + break; +#endif + } +} + +/* + * wld_set_auxilary + * + * Set a field of the auxillary structure + */ +void wld_set_auxilary( ElfW(auxv_t) *av, int type, long int val ) +{ + for ( ; av->a_type != AT_NULL; av++) + if( av->a_type == type ) + av->a_un.a_val = val; +} + +/* + * wld_map_so + * + * modelled after _dl_map_object_from_fd() from glibc-2.3.1/elf/dl-load.c + * + * This function maps the segments from an ELF object, and optionally + * stores information about the mapping into the auxv_t structure. + */ +void* wld_map_so( int fd, void* buf, size_t buflen, ElfW(auxv_t)* av, struct link_map *l) +{ + ElfW(Ehdr) *header = buf; + ElfW(Phdr) *phdr, *ph; + /* Scan the program header table, collecting its load commands. */ + struct loadcmd + { + ElfW(Addr) mapstart, mapend, dataend, allocend; + off_t mapoff; + int prot; + } loadcmds[header->e_phnum], *c; + size_t nloadcmds = 0, maplength; + + header = buf; + phdr = (void*) (((unsigned char*)buf) + header->e_phoff); + + if( header->e_ident[0] != 0x7f && + header->e_ident[0] != 'E' && + header->e_ident[0] != 'L' && + header->e_ident[0] != 'F' ) + { + wld_printf("Not an ELF binary... don't know how to load it\n"); + return NULL; + } + + if( header->e_machine != EM_386 ) + { + wld_printf("Not an i386 ELF binary... don't know how to load it\n"); + return NULL; + } + + maplength = header->e_phnum * sizeof (ElfW(Phdr)); + if (header->e_phoff + maplength > (size_t) buflen) + { + wld_printf("oops... not enough space for ELF headers\n"); + exit(1); + } + + l->l_ld = 0; + l->l_addr = 0; + l->l_phnum = header->e_phnum; + l->l_entry = header->e_entry; + + for (ph = phdr; ph < &phdr[l->l_phnum]; ++ph) + { + +#ifdef DUMP_SEGMENTS + wld_printf( "ph = %x\n", ph ); + wld_printf( " p_type = %x\n", ph->p_type ); + wld_printf( " p_flags = %x\n", ph->p_flags ); + wld_printf( " p_offset = %x\n", ph->p_offset ); + wld_printf( " p_vaddr = %x\n", ph->p_vaddr ); + wld_printf( " p_paddr = %x\n", ph->p_paddr ); + wld_printf( " p_filesz = %x\n", ph->p_filesz ); + wld_printf( " p_memsz = %x\n", ph->p_memsz ); + wld_printf( " p_align = %x\n", ph->p_align ); +#endif + + switch (ph->p_type) + { + /* These entries tell us where to find things once the file's + segments are mapped in. We record the addresses it says + verbatim, and later correct for the run-time load address. */ + case PT_DYNAMIC: + l->l_ld = (void *) ph->p_vaddr; + l->l_ldnum = ph->p_memsz / sizeof (Elf32_Dyn); + break; + + case PT_PHDR: + l->l_phdr = (void *) ph->p_vaddr; + break; + + case PT_TLS: + /* + * We don't need to set anything up because we're + * emulating the kernel, not ld-linux.so.2 + * The ELF loader will set up the TLS data itself. + */ + break; + + case PT_LOAD: + { + if ((ph->p_align & (GL(dl_pagesize) - 1)) != 0) + { + wld_printf("ELF load command alignment not page-aligned"); + return NULL; + } + if (((ph->p_vaddr - ph->p_offset) & (ph->p_align - 1)) != 0) + { + wld_printf("ELF load command address/offset not properly aligned"); + return NULL; + } + + c = &loadcmds[nloadcmds++]; + c->mapstart = ph->p_vaddr & ~(ph->p_align - 1); + c->mapend = ((ph->p_vaddr + ph->p_filesz + GL(dl_pagesize) - 1) + & ~(GL(dl_pagesize) - 1)); + c->dataend = ph->p_vaddr + ph->p_filesz; + c->allocend = ph->p_vaddr + ph->p_memsz; + c->mapoff = ph->p_offset & ~(ph->p_align - 1); + + c->prot = 0; + if (ph->p_flags & PF_R) + c->prot |= PROT_READ; + if (ph->p_flags & PF_W) + c->prot |= PROT_WRITE; + if (ph->p_flags & PF_X) + c->prot |= PROT_EXEC; + } + break; + + case PT_INTERP: + break; + + case PT_SHLIB: + case PT_NOTE: + case PT_GNU_EH_FRAME: + case 0x6474e551: /* FIXME: what is this? */ + break; + + default: + wld_printf("warning: unknown header type %x\n", ph->p_type); + break; + } + } + + /* Now process the load commands and map segments into memory. */ + c = loadcmds; + + /* Length of the sections to be loaded. */ + maplength = loadcmds[nloadcmds - 1].allocend - c->mapstart; + + if( header->e_type == ET_DYN ) + { + ElfW(Addr) mappref; + mappref = (ELF_PREFERRED_ADDRESS (loader, maplength, c->mapstart) + - MAP_BASE_ADDR (l)); + + /* Remember which part of the address space this object uses. */ + l->l_map_start = (ElfW(Addr)) mmap ((void *) mappref, maplength, + c->prot, MAP_COPY | MAP_FILE, + fd, c->mapoff); + /* wld_printf("set : offset = %x\n", c->mapoff); */ + /* wld_printf("l->l_map_start = %x\n", l->l_map_start); */ + + l->l_map_end = l->l_map_start + maplength; + l->l_addr = l->l_map_start - c->mapstart; + + mprotect ((caddr_t) (l->l_addr + c->mapend), + loadcmds[nloadcmds - 1].allocend - c->mapend, + PROT_NONE); + goto postmap; + } + else + { + ELF_FIXED_ADDRESS (loader, c->mapstart); + } + + /* Remember which part of the address space this object uses. */ + l->l_map_start = c->mapstart + l->l_addr; + l->l_map_end = l->l_map_start + maplength; + + while (c < &loadcmds[nloadcmds]) + { + if (c->mapend > c->mapstart) + /* Map the segment contents from the file. */ + mmap ((void *) (l->l_addr + c->mapstart), + c->mapend - c->mapstart, c->prot, + MAP_FIXED | MAP_COPY | MAP_FILE, fd, c->mapoff); + + postmap: + if (l->l_phdr == 0 + && (ElfW(Off)) c->mapoff <= header->e_phoff + && ((size_t) (c->mapend - c->mapstart + c->mapoff) + >= header->e_phoff + header->e_phnum * sizeof (ElfW(Phdr)))) + /* Found the program header in this segment. */ + l->l_phdr = (void *) (c->mapstart + header->e_phoff - c->mapoff); + + if (c->allocend > c->dataend) + { + /* Extra zero pages should appear at the end of this segment, + after the data mapped from the file. */ + ElfW(Addr) zero, zeroend, zeropage; + + zero = l->l_addr + c->dataend; + zeroend = l->l_addr + c->allocend; + zeropage = ((zero + GL(dl_pagesize) - 1) + & ~(GL(dl_pagesize) - 1)); + + /* + * This is different to the dl-load load... + * ld-linux.so.2 relies on the whole page being zero'ed + */ + zeroend = (zeroend +GL(dl_pagesize) - 1) & ~(GL(dl_pagesize) - 1); + + if (zeroend < zeropage) + { + /* All the extra data is in the last page of the segment. + We can just zero it. */ + zeropage = zeroend; + } + + if (zeropage > zero) + { + /* Zero the final part of the last page of the segment. */ + if ((c->prot & PROT_WRITE) == 0) + { + /* Dag nab it. */ + mprotect ((caddr_t) (zero & ~(GL(dl_pagesize) - 1)), + GL(dl_pagesize), + c->prot|PROT_WRITE); + } + memset ((void *) zero, '\0', zeropage - zero); + if ((c->prot & PROT_WRITE) == 0) + mprotect ((caddr_t) (zero & ~(GL(dl_pagesize) - 1)), + GL(dl_pagesize), c->prot); + } + + if (zeroend > zeropage) + { + /* Map the remaining zero pages in from the zero fill FD. */ + caddr_t mapat; + mapat = mmap ((caddr_t) zeropage, zeroend - zeropage, + c->prot, MAP_ANON|MAP_PRIVATE|MAP_FIXED, + ANONFD, 0); + } + } + + ++c; + } + + if (l->l_phdr == NULL) + { + wld_printf("no program header\n"); + exit(1); + } + + (ElfW(Addr)) l->l_phdr += l->l_addr; + (ElfW(Addr)) l->l_entry += l->l_addr; + + return (void*)l->l_entry; +} + +/* + * wld_reserve_wine_memory + * + * This is the reason we are here. + * We want to reserve address space so that the kernel doesn't + * map stuff there. We do this by getting in first before + * anything else is mapped (except this program) and reserve + * the memory we want. + */ +void wld_reserve_wine_memory() +{ + mmap((void*)0x00400000, 0x01000000, PROT_NONE, + MAP_FIXED|MAP_PRIVATE|MAP_ANON, -1, 0); +} + +/* + * wld_start + * + * Repeat the actions the kernel would do when loading a dynamically linked .so + * Load the ELF interperter ld-linux.so and then binary itself. + * + * Note, we assume that the binary is a dynamically linked ELF shared object + * and that ld-linux.so is its ELF interpreter. + */ +void* wld_start( int argc ) +{ + int fd; + unsigned char buf[0x800], interp[0x100]; + void *start; + char **argv = (char**) &argc, **p; + struct link_map map; + ElfW(auxv_t)* av; + + memset( &map, 0, sizeof map ); + + /* skip over the parameters */ + p = ++argv; +#ifdef DUMP_ARG + { + int i; + for( i = 0; i<argc; i++ ) + wld_printf("argv[%x] = %s\n", i, *p++); + if(*p++) + wld_printf("argv[argc] not NULL!!\n"); + } +#else + p+=(argc+1); +#endif + + /* skip over the environment */ + while( *p++ ) + ; + + av = (ElfW(auxv_t)*) p; + wld_dump_auxilary( av ); + + /* reserve memory that Wine needs */ + wld_reserve_wine_memory(); + + /* load the original dynamic loader itself */ + fd = open( LDSO_NAME, O_RDONLY, 0); + if( fd < 0 ) + { + wld_printf( "error: fd = %x\n", fd); + exit(1); + } + read( fd, buf, sizeof buf ); + interp[0] = 0; + start = wld_map_so( fd, buf, sizeof buf, av, &map ); + if( !start ) + exit(0); + close( fd ); + + wld_set_auxilary( av, AT_BASE, map.l_addr ); + +#ifdef DUMP_AUX_INFO + wld_printf("New auxillary info:\n"); + wld_dump_auxilary( av ); + wld_printf("jumping to %x\n", start); +#endif + + return start; +} + +/* + * The _start function is the entry and exit point of this program + * + * It calls wld_start, passing a pointer to the args it receives + * then jumps to the address wld_start returns after removing the + * first argv[] value, and decrementing argc + */ +void _start(void); +__asm ( + ".align 4\n" + "\t.global _start\n" + "\t.type _start,@function\n" +"_start:\n" + "\tcall wld_start\n" + "\tpush %eax\n" + "\txor %eax,%eax\n" + "\txor %ebx,%ebx\n" + "\txor %ecx,%ecx\n" + "\txor %edx,%edx\n" + "\tret\n" +); + --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ loader/preload.h 2004-04-10 21:43:23.000000000 +0900 @@ -0,0 +1,51 @@ +/* + mini loader for ld.so - x86 Linux 2.4.x+ kernels only + + Copyright 2004 Mike McCormack for Codeweavers + + Copyright (C) 1995,96,97,98,99,2000,2001,2002 Free Software Foundation, Inc. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + 02111-1307 USA. + */ + +#define LDSO_NAME "/lib/ld-linux.so.2" + +/* ELF definitions */ +#define ELF_PREFERRED_ADDRESS(loader, maplength, mapstartpref) (mapstartpref) +#define ELF_FIXED_ADDRESS(loader, mapstart) ((void) 0) + +#define __ELF_NATIVE_CLASS 32 +#define MAP_BASE_ADDR(l) 0 +#define MAP_COPY MAP_PRIVATE +#define ANONFD -1 + +#define ElfW(type) _ElfW (Elf, __ELF_NATIVE_CLASS, type) +#define _ElfW(e,w,t) _ElfW_1 (e, w, _##t) +#define _ElfW_1(e,w,t) e##w##t + +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <unistd.h> +#include <sys/mman.h> +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> + +#define GL(x) x + +extern unsigned int GL(dl_pagesize); +

2 2

Re: Regression
by Ivan Leo Murray-Smith 10 Apr '04

10 Apr '04

> Updated to recent (GMT 21:07) CVS, still the same behavior. Apparently the '> fix' didn't really fix all of it, or maybe something else is broken? No, the regression was w a problem with the initial decompression of files, I think it's probably a different problem. Also, downgrading to wine-20030508 didn't help, so this bug is quite probably not related to the regression in any way. I'm not sure what kind of log would be useful. Ivan.

1 0

Re: spec file update [corrected]
by Dmitry Timoshkov 10 Apr '04

10 Apr '04

"Hans Leidekker" <hans(a)it.vu.nl> wrote: > Changelog: > Forward MsiLoadString* to user32.LoadString*. > Forward MsiMessageBox* to user32.MessageBox*. Are you sure that you correctly have figured out number of arguments for that APIs? I can't confirm that you are right. Also you had to remove old stub implementations for replaced entry points. -- Dmitry.

2 1

Re: winehq & 20040408
by Brian Vincent 10 Apr '04

10 Apr '04

> winehq still shows: > > Latest Release: > > Wine 20040309 (diff:s) > released: 2004/03/09 > > Nothing under "Latest News" either. I just updated Latest News, but I didn't update wine_release.template. I didn't want to step on Newman's toes. -Brian

1 0

winehq & 20040408
by Rein Klazes 10 Apr '04

10 Apr '04

Hi, winehq still shows: Latest Release: Wine 20040309 (diff:s) released: 2004/03/09 Nothing under "Latest News" either. Can somebody fix this? Rein. -- Rein Klazes rklazes(a)xs4all.nl

1 0

wine native linux executable /
by Arne Gellhaus 10 Apr '04

10 Apr '04

Hi, I am new to wine and i am trying to get some things done. 1. Is it possible to compile a native linux executable with winelib and use winapi functions like LoadLibrary() and GetProcAddress()? I made my buildsystem with winemaker. 2. I tried to use Common C++ [1] in my winelib application. But because of winelib/wineg++ (?) it assumes that it is running on windows and so the compilation failed. Is it possible to use such portable frameworks in a winelib application like in any other linux application? Thanks for helping me out, Arne Gellhaus [1] http://www.gnu.org/software/commoncpp/

6 9

Re: Security bug in ShellExecuteEx()
by Michael Stefaniuc 09 Apr '04

09 Apr '04

Hello, On Fri, Apr 09, 2004 at 02:14:10AM +0200, Francois Gouget wrote: > Index: dlls/shell32/shlexec.c > =================================================================== > RCS file: /var/cvs/wine/dlls/shell32/shlexec.c,v > retrieving revision 1.40 > diff -u -r1.40 shlexec.c > --- a/dlls/shell32/shlexec.c 7 Apr 2004 03:49:51 -0000 1.40 > +++ b/dlls/shell32/shlexec.c 8 Apr 2004 23:12:53 -0000 > @@ -1114,10 +1126,6 @@ > strcatW(wszApplicationName, wszCommandline); > } > > - retval = execfunc(wszApplicationName, NULL, FALSE, &sei_tmp, sei); > - if (retval > 32) > - return TRUE; > - > /* Else, try to find the executable */ ^^^^^ You may want to remove this because it refers to the just removed if. > wcmd[0] = '\0'; > retval = SHELL_FindExecutable(sei_tmp.lpDirectory, lpFile, sei_tmp.lpVerb, wcmd, 1024, lpstrProtocol, &env, sei_tmp.lpIDList, sei_tmp.lpParameters); 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

3 2

Wine-20040408 Compile Bug
by greensh＠knology.net 09 Apr '04

09 Apr '04

Had a problem compiling this latest version on my Dell Latitude laptop... here is the exact make error; gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -DBINDIR="\"/usr/local/bin\"" -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o keyboard.o keyboard.c keyboard.c: In function `X11DRV_ToUnicodeEx': keyboard.c:2128: error: `XK_EuroSign' undeclared (first use in this function) keyboard.c:2128: error: (Each undeclared identifier is reported only once keyboard.c:2128: error: for each function it appears in.) make[2]: *** [keyboard.o] Error 1 make[2]: Leaving directory `/data/0MD2/wine-20040408/dlls/x11drv' make[1]: *** [x11drv] Error 2 make[1]: Leaving directory `/data/0MD2/wine-20040408/dlls' make: *** [dlls] Error 2 Compilation failed, aborting install. Looks like it's wrong in detecting the keyboard. A fix was to comment out the if statement entirely; < if (keysym == XK_EuroSign) < { < bufW[0] = 0x20AC; < ret = 1; < goto found; < } --- > /* > if (keysym == XK_EuroSign) > { > bufW[0] = 0x20AC; > ret = 1; > goto found; > } > /* Then it compiled/installed fine. Shaun

1 0

abnt2 keyboard fix
by Rafael Ávila de Espíndola 09 Apr '04

09 Apr '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have realised that the tables main_key_scan_abnt_qwerty and main_key_vkey_abnt_qwerty are both wrong. But one error compensates the other. For example, when I press x the message "Translating key VK_Z..." is displayed and an 'x' appears on the screen. The other problem with the abnt2 keyboard is that wine assumes that: /* Only the Keypad keys 0-9 and . send different keysyms * depending on the NumLock state */ This is not true for the abnt2 keyboard. The comma may also work as a delete. The attached patch solves both problems. I have tested the patch with a abnt2 and a us-int keyboard. Both work correctly. One last comment: as far as I know, all abnt2 keyboards have an "alt gr" key. How may I contact Mauro Carvalho Chehab and Raul Gomes Fernandes? Thanks Rafael Ávila de Espíndola -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAdrYZLlrfGJ8JUHwRAkxbAKCdrcsZ52jBWNtGqggmEzCKevhCgwCfclmx 0uNw50qMBFAp5HzZdIBtCjY= =NdP/ -----END PGP SIGNATURE-----

1 0

Serial Port Problem
by TN 09 Apr '04

09 Apr '04

Hi I already posted this on gmane.comp.emulators.wine.user but didn't get a response, maybe I have more luck here. I'm running wine-20040309 on a SuSE 8.2 system and trying to get Keil µVision2 Evaluation Version (Integrated Development Environment for Microcontrollers) working. So far, I've been pretty successful - most of it works. However, connecting a µC-Board at the serial port fails. The traces I get are as follows: fixme:comm:GetCommProperties (0xa0 0x408bf6f0 ) trace:comm:SetCommTimeouts (0xa0,0x42be02f8) trace:comm:SetCommMask handle 0xa0, mask 1 trace:comm:GetCommState handle 0xa0, ptr 0x42be02d8 trace:comm:GetCommState OK trace:comm:GetCommState bytesize 8 baudrate 9600 fParity 0 Parity 0 stopbits 1 trace:comm:GetCommState IXON ~IXOFF trace:comm:GetCommState CRTSCTS trace:comm:SetCommState handle 0xa0, ptr 0x42be02d8 trace:comm:SetCommState bytesize 8 baudrate 9600 fParity 0 Parity 0 stopbits 1 trace:comm:SetCommState IXON ~IXOFF trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:WaitCommEvent (0xa0 0x42f00180 0x42be0328 ) trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:COMM_WaitCommEventService iosb 0x42be0328 trace:comm:GetCommMask handle 0xa0, mask 0x42f00184 trace:comm:ClearCommError handle 0xa0 cbInQue = 1 cbOutQue = 0 err:file:GetOverlappedResult PENDING status after waiting! trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:PurgeComm handle 0xa0, flags f trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:ClearCommError handle 0xa0 cbInQue = 0 cbOutQue = 0 trace:comm:WaitCommEvent (0xa0 0x42f00180 0x42be0328 ) Any help would be greatly appreciated. Thanks. Regards, Thomas

2 1

inheriting exec-shield avoidance
by Peter Riocreux 09 Apr '04

09 Apr '04

I am intermittently trying to get Wine to play nicely with a big EDA tool, and it is doing not too badly today with the 20040309 snapshot on Fedora Core 1. The thing that I think is stopping it working is that whatever is done to stack-shield by the prepending "setarch i386" on invocation is not inherited by the .exe that the program calls. Net result is that I get the "..... security-patched kernel ?" error message from the child process instead of the parent. Progress of a sort. Is there anything, short of turning off exec-shield entirely, that can be done about this? The full set of messages it emits (with program identities obscured to avoid identifying the much-cheaper-when-bought-as-windows-binary application) is below. The printer message mentions an extant queue. ----8<--------8<--------8<--------8<--------8<--------8<---- err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report fixme:console:SetConsoleCtrlHandler (0x41a8af,1) - no error checking or testing yet err:comm:GetCommState tcgetattr error 'Invalid argument' fixme:commdlg:PRINTDLG_OpenDefaultPrinter Could not open printer pica_duplex?! fixme:console:SetConsoleCtrlHandler (0x7800f03e,1) - no error checking or testing yet err:virtual:map_image Standard load address for a Win32 program (0x00400000) not available - security-patched kernel ? wine: could not load L"G:\\path\\to\\my\\child.exe" as Win32 binary ----8<--------8<--------8<--------8<--------8<--------8<---- Peter

4 8

Re: CryptoAPI
by dataphile 09 Apr '04

09 Apr '04

I read in one of the list archives that someone was working on implementing CryptoAPI functionality via libgcrypt on the backend. Anyone have any more info on this?

1 0

Re: wine/dlls/msvcrt math.c
by Hans Leidekker 09 Apr '04

09 Apr '04

On Thursday 08 April 2004 21:49, Alexandre Julliard wrote: > Modified files: > dlls/msvcrt : math.c > > Log message: > Portability fix. > > Patch: http://cvs.winehq.org/patch.py?id=11915 This isn't needed anymore. MinGW has accepted my patch that adds the defines to their header. I think that's the proper fix: they export fpclass() so they should export the corresponding defines for it's return values too. -Hans

1 0

Re: ShellExecute IE compatibility problems
by Martin Fuchs 09 Apr '04

09 Apr '04

On 09.04.2004 02:03:37 Francois Gouget wrote: > > This patch fixes two IE compatibility problems. > > The first one is a mundane issue. IE calls ShellExecuteEx with a NULL > verb. Our implementation fails when it should use some sophisticated > algorithm described in the MSDN to choose a default verb. Well most of > the time we just want 'open' anyway so that's what this patch does. I've > left it as an exercise to the reader to head over to the MSDN and > implement the series of fallbacks we're supposed to implement. This is what SHELL_FindExecutable() tries to do when enumerating the registry keys. What is wrong with that - doesn't this work for you? I don't think we should go back and use "open" again if the verb parameter is NULL. Please correct the current algorithm, if it's not fully compliant. Regards, Martin

1 0

Re: Workaround a SoundBlaster 16 OSS bug
by Andreas Mohr 09 Apr '04

09 Apr '04

Hi, On Fri, Apr 09, 2004 at 02:27:19AM +0200, Francois Gouget wrote: > Note: AFAIK Andreas' kernel patch has never been applied :-( In fact it has been, fortunately, just about two weeks ago... By Andreas Kies in 2.4.26-pre3. He'd already patched 2.6.x a bit earlier. I've been trying to get the slightest bit of attention about that DoS at that time, but after two very detailed fruitless mails to LKML, I just gave up: http://www.uwsg.iu.edu/hypermail/linux/kernel/0206.0/0087.html http://www.uwsg.iu.edu/hypermail/linux/kernel/0206.2/0033.html Andreas Kies told me that it seemed that they now cared a slight wee bit more about small fringe problems such as DoSes in 2.4.x... </sarcasm> > (now you know how to mount a DOS on these systems!) Ow, watch your words! This can be VERY easily misinterpreted as mounting a DOS partition somewhere!? (in fact I did fall for it the first couple of seconds) > Patch the fragment size if it does not match the current sound > format. This saves us from trigerring a kernel freeze on some OSS 2.4 + > SounBlaster 16 systems. Crap, I thought I'd sent a Wine patch at that time; it would have been the easiest thing to do. Anyway, glad to see it fixed now. Greetings, Andi (been finishing my wireless driver any single day for about 5 months now :))

2 1

Re: Regression
by Ivan Leo Murray-Smith 08 Apr '04

08 Apr '04

> Tried to install on an updated (like 45 min old) CVS version to test it, > seems to get in an endless loop here. Alexandre committed a fix http://www.winehq.com/hypermail/wine-cvs/2004/04/0095.html Everything seems OK again, and hopefully will stay so. Ivan.

2 1

Re: Regression
by Ivan Leo Murray-Smith 08 Apr '04

08 Apr '04

> Tried to install on an updated (like 45 min old) CVS version to test it, > seems to get in an endless loop here. You're wright, it loops :( Ivan.

1 0

Re: Re: inheriting exec-shield avoidance
by chmorgan＠charter.net 08 Apr '04

08 Apr '04

Any idea when the kernel and wine changes will be going in? Then we can start asking people with Fedora to disable exec-shield and prelinking OR upgrade to kernel 2.6.X and the latest wine. There are people everyday that come onto #winehq with problems due to prelinking/exec-shield. Thanks, Chris > > From: "Dimitrie O. Paun" <dimi(a)intelliware.ca> > Date: 2004/04/08 Thu PM 03:10:35 EDT > To: Mike McCormack <mike(a)codeweavers.com> > CC: Peter Riocreux <par+wine_devel(a)silistix.com>, <wine-devel(a)winehq.org> > Subject: Re: inheriting exec-shield avoidance > > On Thu, 8 Apr 2004, Mike McCormack wrote: > > > I've attached the source code. The idea is to run it like this: > > > > wld /home/mike/wine/loader/wine-pthread my.exe > > Cool. One small nit: for consistency, can we name it wineld instead? > Or is it winepreld more apropriate? I'm thinking that wineld will > seem to be the counterpart of winegcc... > > -- > Dimi. > > > >

1 0

RE: Status of TAPI
by Robert van Herk 08 Apr '04

08 Apr '04

> This (dutch..) site provides some TAPI patches for Wine that are not > in CVS: > http://home.wanadoo.nl/wijn/girotel/ > > Since I'm dutch, I'd thought I'd explain a bit on what this site says. Wijn is dutch for wine by the way . The site explains how to patch wine in order to be able to use girotel software. Girotel is a telebanking system using dail up by modem that was quite popular a few years ago. Anyway, now-a-days most people use Internet for telebanking, not dail up modem. Although the site for that specific bank is not mozilla compatible , it can be used from Konqueror. The patches seems to be specially suited in order to use this Girotel system. Greetings, Robert

1 0

Status of TAPI
by Andreas Rosenberg 08 Apr '04

08 Apr '04

Hi guys! I'd like to run a TAPI based application in Wine (updated from CVS today). I extracted the vendor specific TAPI driver and the registry keys and included both into a Wine setup. Then I tried to do setup the TAPI driver using the telephon.cpl (taken from Win98): wine rundll32.exe shell32.dll,Control_RunDLL telephon.cpl first I had a problem with the Wine implementation of the TAPI32.DLL. err:module:import_dll No implementation for TAPI32.dll.internalConfig imported from L"C:\\windows\\system\\telephon.cpl", setting to 0xdeadbeef ... No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\TELEPHON.CPL' (0x75a70000) Unhandled exception: page fault on read access to 0xdeadbeef in 32-bit code (0x404c5b7e). who had dug in that DEAD BEEF? ;-) Then I took the TAPI32.DLL from a Win98 installation. This gave me another error: fixme:ole:RpcServerRegisterAuthInfoA ((null),10,(nil),(nil)): stub fixme:seh:EXC_RtlRaiseException call to unimplemented function rpcrt4.dll.NdrClientCall (last message repeated several times). At last I took the rpcrt4.dll from a Windows98 installation and tried it again. Then it took quite a time (~15 sec) until the Wine debugger came up. wine rundll32.exe shell32.dll,Control_RunDLL telephon.cpl wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 8 Can't find file for ELF 'wine-kthread' ((nil)) Loaded debug information from ELF 'wine-pthread' ((nil)) Breakpoint 1 at 0x4000dd60 (_end+0x3fefb8d0) Loaded debug information from ELF '/usr/local/lib/libwine.so.1' (0x40028000) No debug information in ELF '/lib/i686/libpthread.so.0' (0x40040000) No debug information in ELF '/lib/i686/libc.so.6' (0x40091000) No debug information in ELF '/lib/libdl.so.2' (0x401c4000) No debug information in ELF '/lib/ld-linux.so.2' (0x40000000) Loaded debug information from ELF '/usr/local/lib/wine/ntdll.dll.so' (0x401c8000) Loaded debug information from ELF '/usr/local/lib/libwine_unicode.so.1' (0x40238000) No debug information in ELF '/lib/i686/libm.so.6' (0x4032b000) Loaded debug information from ELF '/usr/local/lib/wine/kernel32.dll.so' (0x40460000) Loaded debug information from ELF '/usr/local/lib/wine/rundll32.exe.so' (0x405a2000) Loaded debug information from ELF '/usr/local/lib/wine/user32.dll.so' (0x406c0000) Loaded debug information from ELF '/usr/local/lib/wine/gdi32.dll.so' (0x407f8000) Loaded debug information from ELF '/usr/local/lib/wine/advapi32.dll.so' (0x40878000) No debug information in ELF '/usr/lib/libfreetype.so.6' (0x408b7000) No debug information in ELF '/usr/lib/libfontconfig.so.1' (0x4090d000) No debug information in ELF '/usr/lib/libexpat.so.0' (0x40935000) Loaded debug information from ELF '/usr/local/lib/wine/x11drv.dll.so' (0x40955000) No debug information in ELF '/usr/X11R6/lib/libSM.so.6' (0x4001c000) No debug information in ELF '/usr/X11R6/lib/libICE.so.6' (0x409d3000) No debug information in ELF '/usr/X11R6/lib/libXrandr.so.2' (0x405b6000) No debug information in ELF '/usr/X11R6/lib/libXrender.so.1' (0x409ea000) No debug information in ELF '/usr/X11R6/lib/libXext.so.6' (0x409f2000) No debug information in ELF '/usr/X11R6/lib/libX11.so.6' (0x40a00000) No debug information in ELF '/usr/lib/tls/libGL.so' (0x40afc000) No debug information in ELF '/usr/lib/tls/libGLcore.so.1' (0x40b67000) No debug information in ELF '/usr/X11R6/lib/libXcursor.so.1' (0x410e4000) Unsupported debug information in ELF '/usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2' (0x40025000) Unsupported debug information in ELF '/usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2' (0x41131000) No debug information in ELF '/usr/lib/gconv/ISO8859-1.so' (0x408a9000) Loaded debug information from ELF '/usr/local/lib/wine/imm32.dll.so' (0x41150000) Loaded debug information from ELF '/usr/local/lib/wine/shell32.dll.so' (0x4116e000) Loaded debug information from ELF '/usr/local/lib/wine/ole32.dll.so' (0x411f6000) Loaded debug information from ELF '/usr/local/lib/wine/shlwapi.dll.so' (0x4126a000) Loaded debug information from ELF '/usr/local/lib/wine/comctl32.dll.so' (0x412c1000) No debug information in 32bit DLL 'C:\windows\system\rundll32.exe' (0x405b0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\NTDLL.DLL' (0x401e0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\KERNEL32.DLL' (0x40490000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\ADVAPI32.DLL' (0x40890000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\GDI32.DLL' (0x40810000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\USER32.DLL' (0x406e0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\X11DRV.DLL' (0x40970000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\IMM32.DLL' (0x41160000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RPCRT4.DLL' (0x7fb90000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLE32.DLL' (0x41210000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SHLWAPI.DLL' (0x41280000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\COMCTL32.DLL' (0x412d0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SHELL32.DLL' (0x41190000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSVCRT.DLL' (0x78000000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\TAPI32.DLL' (0x7f960000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\TELEPHON.CPL' (0x75a70000) Unhandled exception: page fault on read access to 0xda62061d in 32-bit code (0x401f999a). In 32-bit mode. 0x401f999a (RtlpWaitForCriticalSection+0x6a [critsection.c:204] in NTDLL.DLL): movl 0x1c(%eax),%eax 204 if ((!crit->DebugInfo) || (!crit->DebugInfo->Spare[1])) continue; The wait time could be an indication that a timeout happened. Anybody has a clue what could be the problem? Regards Andy

4 5

Re: MSYS's sh.exe has trouble reading from stdin on Wine?
by Pouech Eric DMI AEI CAEN 08 Apr '04

08 Apr '04

> wine --debugmsg +all -- sh.exe - does wineconsole -- sh.exe - work ? I fear it's the same old pb of not mapping win32 console semantics on standard unix files without winconsole (anyway, check for the CreateFile which returns 0xffffffff, likely on $CONIN) A+

1 0

MSYS's sh.exe has trouble reading from stdin on Wine?
by Dan Kegel 08 Apr '04

08 Apr '04

Someone's having trouble building my crosstool on msys, so I tried installing msys on my Wine (a home-built 20040213). (This is slightly less crazy than installing Cygwin, I think, but it's still a pretty hard test, I bet.) The installer http://prdownloads.sf.net/mingw/MSYS-1.0.10.exe?download ran just fine until it tried to run the postinstall shell script. Turns out running msys's sh.exe hangs. Running it with wine --debugmsg +all -- sh.exe - and waiting until the output settles into an infinite repeat, I see the repeating section is 0009:Call kernel32.WaitForSingleObject(00000084,0000000a) ret=7105f927 0009: select( flags=12, cookie=0x4060eea8, timeout=1081401202.858741 (+0.009956), handles={0x84} ) 0009: select() = PENDING 0009: *wakeup* signaled=258 cookie=0x4060eea8 0009:Ret kernel32.WaitForSingleObject() retval=00000102 ret=7105f927 0009:Call ntdll.RtlEnterCriticalSection(710a8b0c) ret=71070c98 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=71070c98 0009:Call ntdll.RtlLeaveCriticalSection(710a8b0c) ret=71070cb0 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=71070cb0 0009:Call kernel32.PeekConsoleInputA(ffffffff,4060f150,00000001,4060f12c) ret=7105687a 0009: read_console_input( handle=0xffffffff, flush=0 ) 0009: read_console_input() = OBJECT_TYPE_MISMATCH { read=-1, rec={} } 0009:Ret kernel32.PeekConsoleInputA() retval=00000000 ret=7105687a 0009:Call ntdll.RtlEnterCriticalSection(710a8b0c) ret=71070c98 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=71070c98 0009:Call ntdll.RtlLeaveCriticalSection(710a8b0c) ret=71070cb0 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=71070cb0 0009:Call kernel32.WaitForSingleObject(00000084,0000000a) ret=7105f927 So it kind of looks like it's having trouble reading from stdin? Can someone have a look? It'd be so awesome to be able to run msys on Wine... - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

1 0

Re: abnt2 keyboard
by Dmitry Timoshkov 08 Apr '04

08 Apr '04

"Rafael аvila de EspМndola" <rafael.espindola(a)ic.unicamp.br> wrote: > The attached patch fixes the problem that wine has with the abnt2 (Brazilian) > keyboard. The problem was recently discussed in wine-devel. If you still can't provide more arguments as on wine-devel I don't see a reason why the patch can be accepted. Especially taking into account that the patch contains magic numbers without a little bit of explanation what they are. > While reading dlls/x11drv/keyboard.c I notice that wine does a linear search > to convert a virtKey to a keycode. Could this be optimized/simplified by > pre-computing a vkey2keyc[(e->state & NumLockMask)!=0] table? Feel free to send a patch. -- Dmitry.

1 0

[Fwd: DSD_CreateSecondaryBuffer]
by Robert Reif 08 Apr '04

08 Apr '04

sorry, wrong reply button again.

1 0

DSD_CreateSecondaryBuffer
by Daniel Skorka 07 Apr '04

07 Apr '04

Hi, said function is a stub in Wine-20040309. Is anyone working on implementing it? If not, any pointers on doing so, especially on how this fuction differs from DSD_CreatePrimaryBuffer? Thanks, Daniel Skorka

1 0

Regression
by Ivan Leo Murray-Smith 07 Apr '04

07 Apr '04

This patch http://www.winehq.com/hypermail/wine-cvs/2004/03/0434.html breaks the decompression system used by lots of microsoft software, a screenshot is attached. This breaks the installer of the word 97 viewer, and probably of all office viewers, and it may affect dcom and the installer of other Windows components or Microsoft software. This should be fixed before the next release. The CVS regression testing was done with the word viewer available at http://www.microsoft.com/downloads/details.aspx?FamilyID=9bbb9e60-e4f3-436d… Ivan.

2 1

Re: Documentation: Clarified need for conformance tests.
by Francois Gouget 07 Apr '04

07 Apr '04

On Wed, 7 Apr 2004, Michael Jacobsen wrote: > Hi there. This is my first go at submitting a patch. Let's see if it works. It needs a small s/avalible/available/ and it would be nice to follow the 2-space indentation used in the rest of the doc. Besides that it looks good. Thanks for your contribution. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

1 0

article
by Pouech Eric DMI AEI CAEN 07 Apr '04

07 Apr '04

read on from lwn.net http://www-106.ibm.com/developerworks/linux/library/l-wine/?ca=dgr-lnxw04Fi…

1 0

Virus on wine-patches@winehq.org
by Rolf Kalbermatter 07 Apr '04

07 Apr '04

Could someone please remove the following postings from the archive as they contain viruses? http://www.winehq.org/hypermail/wine-patches/2004/04/0082.html http://www.winehq.org/hypermail/wine-patches/2004/04/0084.html Rolf Kalbermatter

3 2

Re: development speed
by Ivan Leo Murray-Smith 07 Apr '04

07 Apr '04

> The website stats are interesting too: Are these available somewhere? Ivan.

2 1

arch tip #1
by Mike Hearn 07 Apr '04

07 Apr '04

At Dimis request, I've added a new script to the root of the gateway tree. The genpatch program takes a series of patch ids as parameters and can generate and send an email to wine-patches with the combined diff of all the given commits. For example: let's say you are working on a feature. You do 3 commits, to keep the changes physically separate, however you decide the commits are too fine grained to submit all at once, so you want to submit them together. Genpatch makes that easy. Say you commit patch-4, patch-5 and patch-6: ./genpatch -m 4 5 6 will compute the combined differential of all those commits, take the commit log and summary of the first and generate an email from them. The patch will include and new files that were added. Have fun! thanks -mike

1 0

Re: wine/ include/config.h.in dlls/x11drv/xrandr.c ...
by Mike Hearn 07 Apr '04

07 Apr '04

On Tue, 06 Apr 2004 22:57:36 -0500, Alexandre Julliard wrote: > Log message: > Mike McCormack <mike(a)codeweavers.com> > Load the XRandR extension dynamically (with help from Alex Pasadyn). Are we sure this is a good idea? Dynamic version of the X extension libraries are not available on every distro, as traditionally XFree has shipped them statically. I'm not even sure they have stable interfaces. It seems wiser to just statically link libXrandr, seeing that it's only 7.7k

1 0

Window management thoughts
by Mike Hearn 07 Apr '04

07 Apr '04

So, me and Mike have been discussing some ideas for window management in Wine. Currently it hasn't turned into code, but I thought I'd write up what our thoughts were so others could comment and maybe be inspired to write patches. The problem: Currently Wine decides whether to make a window managed or not based on a series of heuristics, in is_window_toplevel in dlls/x11drv/window.c Unfortunately these heuristics are frequently wrong, as they have only limited information to work with (window styles, mostly). In CrossOver, is_window_toplevel is easily the most hacked function in the entire codebase. This manifests itself in a variety of ways: * Windows are marked unmanaged when they shouldn't be. For instance, see WinAmp, Trillian, the Counter-Strike CD Key screen etc: there are tons of examples of this problem. This at best means the window is "nailed" to the screen, at worst it makes the program unusable. * The classic "my game starts but I can't type" problem where keyboard input goes to the terminal instead of the window, due to the lack of focus management in unmanaged windows. * Some programs display splash screens and then pop up errors or question dialogs underneath them. Unmanaged windows are always-on-top -> you cannot get to the underlying managed window and the app appears to hang. * Fullscreen windows are really hard to do properly because they must be managed to work correctly in KDE/GNOME. We currently make certain windows unmanaged typically because we need to control their position or rendering with a high degree of accuracy. Unfortunately some X window managers ignore positioning hints, even when we ask them not to. There is no way to make things like menus and tooltips work correctly with these WMs, so we take the window out of the usual window management mechanism entirely. Unfortunately due to the design of the win32 API there is no simple way to tell the difference between a large menu and the Trillian main window. We could mark our own menus specially to make them unmanaged and have everything else be managed, but we then run into problems with programs that draw their own menus and tooltips, of which there are a truly shocking number. So what is a possible solution? Well, one way forward is to implement another mode, in which Wine makes all windows managed and uses a variety of WM hints to get the desired behaviour. For instance, the PPosition flag asks the WM to place the window where the application requests it to. Some WMs respect this, others do not, in yet others it's a toggleable option. For people with WMs that meet the requirements of Wine all windows could be made managed, and for people that don't use such WMs the old way can still be used. IIRC it's possible to ask the WM for identification which means this setting could be largely autodetected by having blacklists of WMs to use the old mode for (or vice-versa). Unfortunately there's no way to know how well this approach would work, or even if it would work at all, short of trying it. thanks -mike

5 6

Re: Re: wineserver: correctly free the debug ctx
by Pouech Eric DMI AEI CAEN 07 Apr '04

07 Apr '04

> It seems to me this will cause the context to never be freed. I don't > understand the problem with multiple processes, the context is bound > to the debugger thread so it shouldn't make any difference how many > processes are being debugged. Could you please give more details on > the problem? well, problem (sigsev in wineserver) happened when quitting windbg after debugging several processes. I'll try to reproduce it over this weekend. A+

1 0

Re: Game support
by James Perry 07 Apr '04

07 Apr '04

Sorry, meant to send this to the list first time around... >> But I narrowed it down to 3 Wine calls in the >> critical loop: SetEvent, WaitForSingleObject and ResetEvent. >> I tried wrapping each of these functions with >> __asm__("pushfl\n"); at the start and __asm__("popfl\n"); at >> the end to preserve the flags - with this, PECrypt works >> fine and the game gets as far as trying to initialise >> DirectX. Not exactly a neat fix though. > > > Did you have to do all of them, or is it just one function that needs this > treatment? SetEvent definitely needs it. The others possibly don't. But I think it would be more robust to preserve the flag through all of them anyway, in case someone makes a change in future that causes one of the others to clear the direction flag too, which seems quite possible. > Are you sure it's not that we need to set the flag before > jumping to the entrypoint? The flag is normally cleared. PECrypt sets it explicitly, then expects it to remain set across those three API calls. > PECrypt sounds like it should run very early on > in the programs lifetime: how much stuff does it do before hitting this > bug? AFAIK, PECrypt just decrypts and decompresses the executable at startup, then it goes away and the program runs as normal. This bug does happen very early on. > If there is really widespread software that depends on > this behaviour though there is precedent for including a hack for it - see > the DllMain wrapper which preserves %ebx for an example. Certainly anything compressed with PECrypt will depend on the flag being preserved. In general I'd imagine it's quite rare for programs to run with the direction flag set for long periods though. Cheers, James

1 0

ole32.dll_CoRegisterPSClsid
by Paul Ortyl 06 Apr '04

06 Apr '04

Hi, If only ole32.dll.CoRegisterPSClsid() is implemented (empty stub returning '1' is enough) then the application "GeoGeogrid® for Windows©" starts and allows at least some basic operations. (tested with "Baden-Würtemberg AMTLICHE TOPOGRAPHISHE KARTEN" Top50, Version 4) For more info on GeoGrid you may look at: http://swpat.ffii.org/patents/effects/geogrid/index.en.html http://www.eads.net/frame/lang/en/xml/content/OF00000000400004/4/20/534204.… Basically all official topographical maps in Germany are available only through this proprietary application. It would be really useful if ole32.dll.CoRegisterPSClsid() could be implemented in (next) release... TIA Paul Ortyl -- Don't take life too seriously; you will never get out of it alive. -- Elbert Hubbard

1 0

AbiWord on ReactOS
by Steven Edwards 06 Apr '04

06 Apr '04

Note there are still a few minor bugs but for the most part it seems we have a real application working on ReactOS. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

1 0

Re: WININET: move to Windows sockets
by Juan Lang 06 Apr '04

06 Apr '04

> Geoff wrote: > > Or we write our own BIO that wraps up whatever > > glue is desirable on the wine-side. Worst-case > > (and it's not that bad an alternative) is that > > you use a memory-base BIO to encapsulate all I/O > > and worry about moving data to and from "sockets", > > whatever they look like, afterwards. > > That's what I've always done. <snip> > So it's not a bad way to go at all. Yep, in fact the "real" way to do this as far as Wine is concerned is to implement SSL in secur32.dll, since this is where Windows does it. It looks about like this, although as Geoff pointed out to me the API is a bit broken. Doing a BIO inside wininet.dll might be more expedient for Hans, who I think is trying to get as much of Wine as possible ported to MinGW. You guys that know SSL better than I do: patches welcome :) --Juan __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

2 1

Re: Game support
by Ivan Leo Murray-Smith 06 Apr '04

06 Apr '04

> btw, are there already any automated tools for parsing Wine logs? There is the examine-relay perl script in the tools directory, but it's only for relay traces. Ivan.

1 0

Re: development speed
by Brian Vincent 06 Apr '04

06 Apr '04

> Check that out - 5mb of patches for the last 3 months running. A meg of > patches just 6 days into the new month already! > > It seems Wine is moving faster than ever before. The website stats are interesting too: Daily Avg | Monthly Totals Hits Pages Visits| Sites KBytes Visits Pages Files Hits Mar 2004 267733 75495 16582 |268931 157346721 514060 2340347 7064537 8299737 Feb 2004 278180 79217 17199 |279399 203400907 498774 2297305 6994822 8067232 Jan 2004 135477 44930 8341 |154109 90054340 258586 1392848 3591136 4199791 Dec 2003 213993 71246 14408 |243882 138401056 446653 2208643 5725553 6633804 Nov 2003 244427 85277 15766 |254363 153748583 472983 2558310 6268477 7332826 Oct 2003 275663 111913 17352 |260400 161803798 537913 3469326 7430846 8545582 Sep 2003 156860 50508 10393 |173365 93441224 311790 1515269 4048260 4705814 Aug 2003 209530 69084 12812 |218040 124270932 397177 2141613 5612004 6495449 Jul 2003 243646 105136 12253 |197296 123038700 379853 3259216 6704428 7553047 Jun 2003 253998 109167 12250 |160468 91985851 306270 2729185 5642823 6349961 May 2003 262218 111683 13764 |207954 105320483 399181 3238809 6336486 7604349 Skipping to the KBytes and Hits columns, things are up. Even more interesting is in Feburary we got Slashdotted and in March we didn't. So it appears people are interested. Generally things begin to taper off as we approach summer. Last year we got some good PR by doing an interview series, so I'm planning on doing that again. Anyone know what happened on October 5th and 6th that generated so many hits? -Brian

1 0

Compiling Wine with BiDi support - instructions
by Shachar Shemesh 06 Apr '04

06 Apr '04

Hi list, Here are the formal instructions for compiling Wine with bidi support. When doing so, it is recommended that you use a fairly recent version of ICU (2.6 and up), or else there is going to be a runtime soft dependancy on some ICU files in the resulting Wine. No big deal - if these files are not there, Wine will work just fine, only without BiDi support. Still, this is not necessary. Instructions: 1. If you use a precompiled package (relatvely rare for ICU, unfortunatly), make sure it has the static libraries as well. ICU does not have these by default. If they are there, you may skip to step 8. Please note, however, that this will add about 7MB to the size of the resulting gdi.dll.so. 2. Grab ICU from the web http://oss.software.ibm.com/icu. 3. Extract the sources file. 4. CD into the ICU directory, and then into the "source" subdirectory. 5. Delete all files with the "mk" extension under icu/source/data. e.g. run "find data -name \*.mk -exec rm \{\} \;". Please trust me on this one, it's ok to do it. This step saves the aforementioned 7MB. 6. ./runConfigureICU LinuxRedHat --enable-static. If you are only building this for use with Wine, you can also add "--enable-shared=no --enable-64bit-libs=no --prefix=~/icuinstall". If not, you may wish to skip the previous step as well. 7. run "make" and "make install". Grab a lunch. Just one will do. 8. If your ICU library files are installed in /usr/lib and /usr/include, compile wine as usual. If they are installed anywhere else, you will need to set the "ICU_LIB_DIR" environment variable to wherever it was that they are installed. You will also have to add the include path. For example, if you compiled and installed icu according to my example above, you will need to set ICU_LIB_DIR to "~/icuinstall/lib", and also CPPFLAGS to "-I~/icuinstall/include". 9. Make sure that including "ubidi.h" and the following linking step passes in "configure". Also check whether include/config.h has "HAVE_ICU" set. 10. To be really sure that your wine supports BiDi, run the program given in this email. A few things to note: * The above assumes that your Wine already has http://www.winehq.org/hypermail/wine-patches/2004/04/0088.html integrated. * If you are compiling Wine on Debian, and want to use the Debian supplied ICU library for whatever reason (for example - because the packaging system pretty much requires you to), the above procedure needs to be slightly altered. ICU changed their static library naming scheme over some recent version. The Debian packaged ICU (2.1) still uses the old scheme. Either use Wine without the aforementioned patch, or set ICUUC_LIB and ICUDATA_LIB to the full path to libicuuc.a and libicudata.a respectively (they are called "libsicuuc.a" and "libsicudata.a" in newer version of ICU). Please note that this means there is a runtime dependancy on some ICU files for BiDi to work, as explained above. Instead of reposting the program for testing whether Win32 supports reordering, the link to the file in the list's archive is at http://www.winehq.org/hypermail/wine-devel/2003/08/att-0175/01-biditest.c. Enjoy -- Shachar Shemesh Lingnu OpenSource Consulting http://www.lingnu.com/

1 0

Re: Dos INT15
by Dmitry Timoshkov 06 Apr '04

06 Apr '04

"Florian Goth" <Captainsifff(a)gmx.de> wrote: > Added some more stubs after examining the dosbox source code Could you please try to stick to the formatting style used in the file in your changes? -- Dmitry.

1 0

development speed
by Mike Hearn 06 Apr '04

06 Apr '04

Hey guys, http://www.winehq.org/hypermail/wine-patches/ Check that out - 5mb of patches for the last 3 months running. A meg of patches just 6 days into the new month already! It seems Wine is moving faster than ever before. To put things in perspective, the Wine source tree is 10mb - that means in only 2 months as many lines of patch were generated as exists in Wine itself! thanks -mike

2 2

Re: WININET: move to Windows sockets
by Dan Kegel 06 Apr '04

06 Apr '04

Geoff wrote: > Or we write our own BIO that wraps up whatever glue is desirable on the > wine-side. Worst-case (and it's not that bad an alternative) is that you > use a memory-base BIO to encapsulate all I/O and worry about moving data > to and from "sockets", whatever they look like, afterwards. That's what I've always done. And it seems I've managed (via the rant at http://kegel.com/ssl/api.html) to convince Sun to make that the standard way to do ssl with NIO under the next JDK, kinda. So it's not a bad way to go at all. - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

1 0

Re: appdb - improvement in serching out bugs
by tony_lambregts＠telusplanet.net 06 Apr '04

06 Apr '04

Quoting hatky <hatky(a)hatky.myz.info>: > > On Sunday 04 April 2004 06:21, tony_lambregts(a)telusplanet.net wrote: > > The current code can get bugs that have nothing to do with the AppDB. > This > > should fix it. > > > > -- > > > > Tony Lambregts > > I think this is wrong, you are saying the url in bugzilla should be exactly > "appdb #" where it should realy be > "http://bugs.winehq,org/show_bug.cgi?id=#" > > No, no, no... read the patch again. The current code is correct as far as it goes, but it grabs the substring. So when the appdb# is 68 it grabs bugs that for appid 680, 681... 689. It will also grab bugs that just happen to have 68 in the url. My testing with this has been limited somewhat since I have not been able to set up the appdb on my machine but I know enough to know that the code as I have submitted will do what it needs to do. -- Tony Lambregts

2 1

DDraw issues, etc.
by Tim Hentenaar 06 Apr '04

06 Apr '04

Hi all, I've implemented SetClipList and GetClipList in the DirectDraw Clipper, and I'm wondering how I should go about implementing clipping in DirectDraw's Blt() (if it isn't already done somewhere). M$'s documentation isn't too great, so I figured I should ask around. There's a game one of my relatives wants to run under Linux (it's a children's program), and the major problem is that it dosen't seem to handle clipping properly when blitting. (e.g. every time you move the mouse, it calls SetClipList). FYI, the binkw32.dll that came with the program was originally causing it to hang, but I patched the DLL and it works fine. If anyone else has had such problems, I could provide a patch. Also, I'm going to take a look at some of the DirectSound stuff too. The sound isn't very good quality for some reason, but under the WineX 3.3 CVS, sound works perfectly. Tim

3 11

Re: WININET: move to Windows sockets
by Juan Lang 06 Apr '04

06 Apr '04

Hans wrote: > On Monday 05 April 2004 19:24, Alexandre Julliard > wrote: > > There's no real reason that we cannot use Unix > > sockets on Unix and Windows socket on Reactos with > > the same code, it just needs a bit of header magic; > > and this will be useful for Winelib apps too. > > Hmm, I'd like to agree with that. I'd be rather nervous about the mixing of OpenSSL with the use of Winsock, at least as is. OpenSSL is itself using socket read/write calls, and it expects them to be the correct ones: in particular, the UNIX ones. I believe the only way to do this correctly is to write a new OpenSSL BIO that uses the same read/write/open/close calls as the rest of netconnection.c, and this can be combined with the aforementioned header magic to get what you're after. Copying and pasting an existing OpenSSL BIO would probably suffice. --Juan __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

2 1

Re: wineserver: correctly free the debug ctx
by Alexandre Julliard 05 Apr '04

05 Apr '04

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > when a debugging thread is attached to several processes, the debug > context (shared across all processes) is destroyed when the first > process terminates. This patch destroys it when the last process > attached terminates. It seems to me this will cause the context to never be freed. I don't understand the problem with multiple processes, the context is bound to the debugger thread so it shouldn't make any difference how many processes are being debugged. Could you please give more details on the problem? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: WININET: move to Windows sockets
by Steven Edwards 05 Apr '04

05 Apr '04

Hello Hans, --- Hans Leidekker <hans(a)it.vu.nl> wrote: > > This makes wininet build on MinGW. > > Changelog: > Move to Windows sockets. > I asked Alexandre about a patch to move Wininet to Winsock and he said it took to much of a performance hit to merge. Is there a way we can bench mark it to show how much of a hit Winsock vs Unix sockets is going to give us? He suggested that we find a way to make Wininet use Unix sockets on Unix and Winsock on Windows. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

6 7

Re: appdb - improvement in serching out bugs
by hatky 05 Apr '04

05 Apr '04

On Sunday 04 April 2004 06:21, tony_lambregts(a)telusplanet.net wrote: > The current code can get bugs that have nothing to do with the AppDB. This > should fix it. > > -- > > Tony Lambregts I think this is wrong, you are saying the url in bugzilla should be exactly "appdb #" where it should realy be "http://bugs.winehq,org/show_bug.cgi?id=#" -- Hatky, Worshiper of wine (http://www.winehq.org/), Impossible is only an opinion.

1 0

CryptoAPI
by "Jacek [KRunch] Chałupka" 05 Apr '04

05 Apr '04

Has anybody started implementing CryptoApi in WINE?? If no mayby someone can give me some clues how to start... I am not bad i C++ I think, but I have never make thing like that. I don't promise I will do that, but I can try... :)

3 2

Re: CryptoAPI
by Juan Lang 05 Apr '04

05 Apr '04

Jacek wrote: > Has anybody started implementing CryptoApi in WINE?? > If no mayby someone can give me some clues how to > start... I am not bad i C++ I think, but I > have never make thing like that. I don't promise I > will do that, but I can try... :) Hi Jacek, take a look at Wine's rsabase.dll, that DLL doesn't do very much yet. All its functions (CPAcquireContext, etc) are described here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/s… If you have access to a Windows box it's easier: you can load the DLL itself and call all the functions and try to reproduce what it's doing. Good luck, --Juan __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

1 0

Re: Fwd: Re: appdb - improvement in serching out bugs
by tony_lambregts＠telusplanet.net 05 Apr '04

05 Apr '04

Quoting hatky <hatky(a)hatky.myz.info>: >> No, no, no... read the patch again. > Ok, sorry wasn't what I tought you are trying to do, this patch is ok > p.s. I didn't think someone actually changed the urls in bugzilla. sweet :). I have been going through them 100 at a time. I've got 1-400 done at this time. I figure I will be done sometime before Christmas :P. If anyone wants to help with this I would be glad to have the help... Check out http://bugs.winehq.org/show_bug.cgi?id=560 for more more on this. -- Tony Lambregts

1 0

NtPulseEvent
by Robert Lunnon 05 Apr '04

05 Apr '04

What is the status of NtPulseEvent it emits a diagnostic messages fixme:ntdll:NtPulseEvent (7c,0) yet it looks to me that NtPulseEvent is implemented but the fixme is bogus Anyone know about this ? BTW Has anyone experience with the Skype application under linux, does it work there ? Bob b

2 1

Should winemaker be able to handle this
by Bill Medland 05 Apr '04

05 Apr '04

I haven't been following the winemaker stuff so I don't know whether it is supposed to be able to handle this (and is broken) or not. I am having to play with the "build a builtin dll to wrap a linux so" concept again after a year or so since the last time, as discussed in the Winlib manual, chapter 5. I see that winemaker has changed since then. In particular the bit that is not working for my case is the -D, -I, -L and -l options. What I want is to run winemaker to generate the build environment and then do the build. What I used toi have was: #! /bin/bash # Run this script in order to pass the correct arguments to winemaker so that # it can set up the build environment winemaker --nosource-fix --nogenerated-specs --dll --single-target mytarget --nomfc -DMY_SETTING -I$MY_INC_DIR -L$MY_LIB_DIR -lmylinuxso . I see that we don't bother with generating spec files any longer. However I see that the -D, -I, -L and -l options don't find their way into the Makefile these days. Is that by design or a bug? (i.e. do I have to fix winemaker or do I need to look at a different way of doing it) -- Bill Medland mailto:billmedland@mercuryspeed.com http://webhome.idirect.com/~kbmed

4 5

RE: Handling dialogs created without using templates
by Santosh Siddheshwar 05 Apr '04

05 Apr '04

Hi, Thanks. Would you be able to share details of the changes you did for handling MDI windows? Regards Santosh > -----Original Message----- > From: Dmitry Timoshkov [SMTP:dmitry@baikal.ru] > Sent: Tuesday, March 30, 2004 7:40 PM > To: Santosh Siddheshwar > Cc: wine-devel(a)winehq.com > Subject: Re: Handling dialogs created without using templates > > "Santosh Siddheshwar" <santosh.s(a)sonata-software.com> wrote: > > > Yes attached is a sample which is pretty similar to what I described > > below. > > Thanks. Now I see where the problem is. We have to hook dialog creation > code into common window creation code, something similar to what I've done > recently for MDI. Alexandre, are my thoughts correct? > > -- > Dmitry. ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

2 1

Re: Re: dbghelp
by Pouech Eric DMI AEI CAEN 05 Apr '04

05 Apr '04

> UnDecorateName is still a stub, while our winedump has some a good > framework for UnDecorateName, also translating into a GCC way and not in a > VC++ way. How should these things go together? See the comment in dbghelp.c !! My first thouhgt would be to make a .a lib out of winedump code, and use it in winedump and msvcrt and / or dbghelp. I haven't studied yet the best way to share the code between msvcrt and dbghelp A+

1 0

Re: appdb - improvement in serching out bugs
by tony_lambregts＠telusplanet.net 04 Apr '04

04 Apr '04

Quoting hatky <hatky(a)hatky.myz.info>: > > On Sunday 04 April 2004 06:21, tony_lambregts(a)telusplanet.net wrote: > > The current code can get bugs that have nothing to do with the AppDB. > This > > should fix it. > > > > -- > > > > Tony Lambregts > > I think this is wrong, you are saying the url in bugzilla should be exactly > "appdb #" where it should realy be > "http://bugs.winehq,org/show_bug.cgi?id=#" > > No, no, no... read the patch again. The current code is correct as far as it goes, but it grabs the substring. So when the appdb# is 68 it grabs bugs that for appid 680, 681... 689. It will also grab bugs that just happen to have 68 in the url. My testing with this has been limited somewhat since I have not been able to set up the appdb on my machine but I know enough to know that the code as I have submitted will do what it needs to do. -- Tony Lambregts

1 0

Re: dbghelp
by Uwe Bonnes 04 Apr '04

04 Apr '04

>>>>> "Eric" == Eric Pouech <pouech-eric(a)wanadoo.fr> writes: Eric> Eric Pouech a écrit : >> This is a first (and incomplete) shot at implementing the dbghelp >> DLL. Eric> forgot to say that: - this patch must be applied before the ones Eric> on imagehlp & taskmgr - code is highly derivated from winedbg Eric> current code Eric> I'm also working on a winedbg version based on this DLL, but it Eric> isn't ready yet (as dbghelp seems to get a bit more mature, I Eric> thought some people might be interested in testing it) UnDecorateName is still a stub, while our winedump has some a good framework for UnDecorateName, also translating into a GCC way and not in a VC++ way. How should these things go together? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Personal tree with interesting patches
by Mike Hearn 04 Apr '04

04 Apr '04

Hi, As I'm pretty busy right now and won't have time to work on the various misc projects I've been working on up until recently for the foreseeable future, I'm checking them into my personal arch archive for people to play with and maybe work on themselves. My archive co-ordinates: http://navi.cx/~mike/archive/2004 mike(a)navi.cx--2004 so, you'd use: $ tla register-archive http://navi.cx/~mike/archive/2004 There are currently only two interesting branches: wine--mainline--0.9: misc patches that were never applied for whatever reason, debug delay, lockwindowupdate (disabled), that sort of thing as i find more patches around my system i'll check them in for safekeeping wine--loadarea-reserve--0.9 execshield/prelink work, see the log message in patch-1 for details on what remains to be done Have fun! thanks -mike

2 2

installation program
by Brian Vincent (C) 04 Apr '04

04 Apr '04

On the To Do List (c.4) is an item for having a new graphical Wine install program. Anyone ever looked at Frank Hendrickson's WineTools program? http://franksworld.net/winetools.html It used to be written in some funky language, now it's all shell script. Anyway, if you look at the script (wt210) you'll notice he uses xdialog ( http://thgodef.nerim.net/xdialog/ ) for the GUI. So here's what I'm wondering.. How feasible would it be for Wine to create a new Winelib program (say, wdialog) and use a similar concept as Frank? wdialog would simply replicate the functionality of xdialog. We could potentially fail gracefully into shell mode if Wine can't start. It might be a cheap and simple way to get a GUI front-end. Of course, all this requires sane defaults so Wine can actually run wdialog. Any thoughts? --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

1 0

Microsoft SDK samples
by Jonathan Wilson 04 Apr '04

04 Apr '04

Has anyone given thought to using the Microsoft SDK samples (e.g. DirectX samples) to improve WINE? i.e. take a particular sample and work away at it untill what you get in WINE matches what you get in Windows. Although I suspect that there are things that the MS samples dont cover :)

2 1

winapi_stats
by Tom 03 Apr '04

03 Apr '04

Hi, http://www.winehq.org/site/winapi_stats Is incorrect as it shows Total 19640 100% 100% would be nice but its incorect! Tom

3 6

Re: Documentation for GDI Region Functions
by Alexandre Julliard 03 Apr '04

03 Apr '04

Robert Shearman <R.J.Shearman(a)warwick.ac.uk> writes: > and renamed the variables to Microsoft conventions. Please don't do that. The variable names don't matter at all for compatibility, so we don't have to follow the brain-damaged Microsoft conventions for them. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Developer's path to Windows/*NIX multi-platform?
by Dimitrie O. Paun 03 Apr '04

03 Apr '04

You ask: > I am willing to re-write my best Windows software from scratch, but I > insist that the result is native or almost on Linux so there are not any > weird GUI glitches. Do you think Wine is the way to go for me, or am I > better off writing individual versions and keeping the Windows software > native and then producing QT or GTK versions for *NIX? I'm at a cross-roads > here, since I'll be dedicating years of work in whatever direction I take. IMO Wine is the perfect tool for you. We know, it's not perfect. But the best use of your time (and the most efficient) would be to: 1. Fix any problems in your apps (like reliance on strange Windows corner cases, use of very obscure features) 2. Help out fix Wine so that your apps run properly. This will not only help us a lot, but it will help you make good use of your time, and it will allow you to do cross platform development (even for Windows) from your Linux box. Please direct questions to wine-devel(a)winehq.org, where people can help you out. -- Dimi.

7 9

W95INF32 implementation, incase it's useful to anybody
by Mike McCormack 03 Apr '04

03 Apr '04

Hi All, In the process of understanding another bug, I did a little work to implement w95inf32, which appears to be a small IE/win9x only DLL and which is probably of not much use to Wine. It appears to be a think wrapper 32bit around 4 functions in SETUPX. So this is just for documentation purposes, and incase anybody is curious or finds a real need for this DLL. Mike --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ dlls/w95inf32/Makefile.in 2004-03-30 12:03:27.000000000 +0900 @@ -0,0 +1,20 @@ +#MKDLL_SKIP +TOPSRCDIR = @top_srcdir@ +TOPOBJDIR = ../.. +SRCDIR = @srcdir@ +VPATH = @srcdir@ +MODULE = w95inf32.dll +IMPORTS = setupapi kernel32 +ALTNAMES = w95inf16.dll + +SPEC_SRCS16 = $(ALTNAMES:.dll=.spec) + +C_SRCS = \ + w95inf32.c + +@MAKE_DLL_RULES@ + +w95inf16.spec.c: w95inf16.spec + $(WINEBUILD) $(DEFS) $(DLLFLAGS) -o $@ --main-module $(MODULE) --spec $(SRCDIR)/w95inf16.spec + +### Dependencies: --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ dlls/w95inf32/w95inf32.c 2004-03-29 17:07:20.000000000 +0900 @@ -0,0 +1,91 @@ +/* + * W95INF32 - This is a small 32bit interface to SETUPX + * + * Copyright 2004 Mike McCormack for CodeWeavers + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include <stdarg.h> +#include "windef.h" +#include "winbase.h" +#include "winuser.h" + +#include "setupapi.h" + +#include "wine/debug.h" + +WINE_DEFAULT_DEBUG_CHANNEL(w95inf32); + +BOOL WINAPI CtlSetLddPath32( LPSTR x, LPSTR y ) +{ + FIXME("%s %s\n", debugstr_a(x), debugstr_a(y) ); + return FALSE; +} + +BOOL WINAPI GenFormStrWithoutPlaceHolders32( LPSTR dst, LPCSTR src, LPCSTR filename ) +{ + HINF hinf; + DWORD ret = 0; + + FIXME("%p %s %s\n", dst, debugstr_a(src), debugstr_a(filename) ); + + hinf = SetupOpenInfFileA( filename, NULL, INF_STYLE_WIN4, NULL ); + if( !hinf ) + return GetLastError(); + + /* FIXME: call LookupStringInTable? */ + strncpy(dst, src, MAX_INF_STRING_LENGTH ); + + SetupCloseInfFile( hinf ); + + return ret; +} + +DWORD WINAPI GenInstall32(LPCSTR filename, LPCSTR section, LPCSTR directory, DWORD flags) +{ + HINF hinf; + void *context; + DWORD ret = 0; + + ERR("%s, %s, %s, %08lx\n", filename, section, directory, flags ); + + hinf = SetupOpenInfFileA( filename, NULL, INF_STYLE_WIN4, NULL ); + if( !hinf ) + return GetLastError(); + + context = SetupInitDefaultQueueCallback( 0 ); + if (!SetupInstallFromInfSectionA( 0, hinf, section, flags, 0, NULL, + SP_COPY_NEWER_OR_SAME, SetupDefaultQueueCallbackA, + context, 0, 0 )) + { + ret = GetLastError(); + ERR("Failed %08lx\n",ret); + } + + SetupTermDefaultQueueCallback( context ); + + SetupCloseInfFile( hinf ); + + return ret; +} + +BOOL WINAPI GetSETUPXErrorText32(long a, long b, long c) +{ + FIXME("\n"); + return FALSE; +} + --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ dlls/w95inf32/w95inf32.spec 2004-03-29 17:04:15.000000000 +0900 @@ -0,0 +1,9 @@ +# w95inf32 functions have @nn in their names... +# winebuild removes the last @xx in a function name. + +1 stdcall CtlSetLddPath32@8@8(str str) CtlSetLddPath32 +2 stdcall GenFormStrWithoutPlaceHolders32@12@12(ptr str str) GenFormStrWithoutPlaceHolders32 +3 stdcall GenInstall32@20@20(str str str long) GenInstall32 +4 stdcall GetSETUPXErrorText32@12@12(long long long) GetSETUPXErrorText32 +5 stub w95thk_ThunkData32 +

1 0

When saving a file with staroffice it is not saving with extension.
by Ravi Kumar 02 Apr '04

02 Apr '04

Hello Sir, I am working with wine for some time now. I faced with a problem, whenever i am saving a file from Windows version of Staroffice from wine it is saved without extension. I think it is a problem with wine, as staroffice in windows stores files with extensions. I am using wine-20031118 version. Can anybody help me out in this regard. I will also check out to see if it has been solved in later versions. Thanking in advance. regards, ravi.

3 2

Development CDs for Windows
by Steven Pignataro 02 Apr '04

02 Apr '04

I have a large amount of Windows Development CDs....i am wondering if these would be of any interest to the Development team of Wine.... I think that these would become very usefull at developing for Wine as well as alot of what Windows does is still most of the same. They are Windows NT 4 development kits and much much more. We where going to chuck them at my school...but salaviged them Please let me know Thanks -- Steven Pignataro A+ Partner/ CSO Computer Vision Networks, Inc. Toll Free: 866-897-8896 Phone: 269-979-5582 Fax: 269-288-0418 http://www.computervisions.net/ (c)2002-2004 --

1 0

Re: Developer's path to Windows/*NIX multi-platform?
by greensh＠knology.net 02 Apr '04

02 Apr '04

> integration. Ideally, we will have a GTK theme and a QT theme > that just calls the respective toolkit's theming code, so a > Wine app will look native both in GNOME and in KDE. I 100% agree > that native integration is paramount, and this is why we will > have it. This sounds very good. Maybe someday. > Since you've mentioned the toolkits, a small comment on that. > Of the two only QT is a serious option for cross-platform development. > It's a good option, but it's not perfect because your application > will not be native in GNOME, Well not to start a KDE vs Gnome debate, but Gnome is way behind KDE development... it doesn't even support Superkaramba (last I checked). Gnome users typically do not prefer KDE or Qt, and part of that stems from that KDE was developed using Qt and it's integration is woven throughout. > you will not be using the native toolkits > in Windows, you have to pay a lot of licensing fees, etc. You only pay licensing if your Qt app is commercial. The free version is perfect for opensource (ie GPL software) hence why it's included in almost all linux distros and you can D/L the same version for winders. Maybe > wxWindows is a better option... It requires too many code changes (at least in Python) for easy cross-compiling. In Qt you simply generate a .pro file for the platform. Shaun > > -- > Dimi. > > > > >

2 1

Re: GDI: Merge the enhmfdrv into one .c file.
by Mike McCormack 02 Apr '04

02 Apr '04

I object! Being one of the people who sometimes works on EMFs, I don't like this change. A flat namespace in my mind meants that we have one dll's code in each subdirectory in wine/dlls, not that there's no other subdirectories under those. It's a bad precedent to set that each dll can have no further subdirectries. I don't think this change is necessary, and it's going to make the EMF code harder to manage, since the file you've created is very big. Ditto for the MF change. Mike Dimitrie O. Paun wrote: > Merge the entire enhmfdrv into one .c file. > It's not big, and it's the way we usually do > things in wine (e.g. dlls/comctl32/*.c). > Moreover, we get rid of the extra dir in > dlls/gdi/, and gets us closer to a flat > dlls/*/ namespace.

2 2

Re: Developer's path to Windows/*NIX multi-platform?
by greensh＠knology.net 02 Apr '04

02 Apr '04

At work we write A LOT of 3D graphics code that has requirements to run on winders/linux/macintosh. Qt has definitely proved the way to go (5 years now) with only minor changes required and then it worked on ALL platforms. Java and Python were too slow and required too many code changes for each platform, whereas Qt worked with our existing C/C++ code nicely. BTW, a real good book that's out now is "C++ GUI Programming with Qt 3" by Jasmin Blanchette and Mark Summerfield. It starts very basic from Hello World. It's worth the $30. I'd have to say, so far from what I've seen Wine still has a long way to go before it's ready for production, and reliable use... it's getting there but just not there yet. It's great for porting apps, but too poorly documented for actual development. I mean this forum is about it and you're lucky if you can get answers. But thanks to all the helpful people here, maybe it will grow. Shaun On Thu, 1 Apr 2004 17:39:14 -0500 (EST), "Dimitrie O. Paun" <dimi(a)intelliware.ca> wrote : > > You ask: > > > I am willing to re-write my best Windows software from scratch, but I > > insist that the result is native or almost on Linux so there are not any > > weird GUI glitches. Do you think Wine is the way to go for me, or am I > > better off writing individual versions and keeping the Windows software > > native and then producing QT or GTK versions for *NIX? I'm at a cross-roads > > here, since I'll be dedicating years of work in whatever direction I take. > > IMO Wine is the perfect tool for you. We know, it's not perfect. > But the best use of your time (and the most efficient) would be to: > 1. Fix any problems in your apps (like reliance on strange Windows > corner cases, use of very obscure features) > 2. Help out fix Wine so that your apps run properly. > > This will not only help us a lot, but it will help you make good > use of your time, and it will allow you to do cross platform > development (even for Windows) from your Linux box. > > Please direct questions to wine-devel(a)winehq.org, where people > can help you out. > > -- > Dimi. > > > > > > >

2 1

abnt2 delete keys problem
by Rafael Ávila de Espíndola 02 Apr '04

02 Apr '04

I am having the following problem with a abnt2 (Brazilian) keyboard: When the numlock is off both delete keys work correctly. If the numlock is on both key produce a delete plus a comma. The message http://www.winehq.org/hypermail/wine-patches/2002/12/0329.html appears to describe the same problem. But the proposed patch didn't work for me. Attached is a xev log. The numlock is initially on. Them the I press the middle keyboard delete, keypad delete, numlock, middle keyboard delete and keypad delete. Thanks for any help. Rafael Ávila de Espíndola

2 4

MFC app compile problems with AFX
by greensh＠knology.net 01 Apr '04

01 Apr '04

Since I was told the winlib docs are out of date, I'll try posting this problem. winemaker --interactive seems to have worked and converted the 'winders' source .cpp and .h files and made the backups fine. It only created one file; Makefile When I type 'make' it produced a bunch of afx errors needing only five afx*. h files, so I copied these over from the VS6 directory, ran 'make clean', but hen it needed a ton more, so I copied them all afx*.h and afx*.inl. Then 'make' gets all the way down to the first errors; /usr/local/include/wine/windows/rpcndr.h:383: error: non-local function ` <anonymous struct>* NDRSContextUnmarshall2(void*, void*, long unsigned int, void*, long unsigned int)' uses anonymous type In file included from afxdtctl.h:19, from StdAfx.h:18, from ArbreNiv.cpp:2: afxdisp.h:75: warning: malformed '#pragma pack(push[, id], <n>)' - ignored afxdisp.h:1182: error: friend declaration requires class-key, i.e. `friend struct COleDateTimeSpan' afxdisp.h:1259: error: friend declaration requires class-key, i.e. `friend class COleDateTime' afxdisp.h:1408: warning: #pragma pack (pop) encountered without matching #pragma pack (push, <n>) In file included from afxdisp.h:1413, from afxdtctl.h:19, from StdAfx.h:18, from ArbreNiv.cpp:2: afxole.inl: In constructor `COleVariant::COleVariant(const CHAR*)': afxole.inl:97: error: `vt' undeclared (first use this function) afxole.inl:97: error: (Each undeclared identifier is reported only once for each function it appears in.) afxole.inl: In constructor `COleVariant::COleVariant(unsigned char)': afxole.inl:101: error: `bVal' undeclared (first use this function) afxole.inl: In constructor `COleVariant::COleVariant(const COleCurrency&)': afxole.inl:103: error: `cyVal' undeclared (first use this function) afxole.inl: In constructor `COleVariant::COleVariant(float)': afxole.inl:105: error: `fltVal' undeclared (first use this function) afxole.inl: In constructor `COleVariant::COleVariant(double)': afxole.inl:107: error: `dblVal' undeclared (first use this function) afxole.inl: In constructor `COleVariant::COleVariant(const COleDateTime&)': afxole.inl:109: error: `date' undeclared (first use this function) afxole.inl: In member function `DWORD COleSafeArray::GetDim()': afxole.inl:283: error: `parray' undeclared (first use this function) Can anyone help? Any ideas for me to try? I can run the winders executable with wine, but it's very buggy and will crash easily, so I wanted to use winelib. Shaun

2 1

ANNOUNCE: CVS to arch gateway
by Mike Hearn 01 Apr '04

01 Apr '04

Hi everybody, I'm pleased to announce the public availability of a gateway from WineHQ CVS to the GNU arch version control system. It marks the beginning of an experiment not just in new forms of source control, but in new ways for the Wine project to be organized and function. Nobody knows if it will catch on, but a few of us (me, dimi and alexandre) have been discussing trying out arch for some time. Carpe dium! ==================================================================== For those who already know arch, here are the details: archive coordinates: http://navi.cx/mike/wine/archive mike(a)winehq.org--wine/wine--mainline--0.9 It is synchronised with CVS on the hour, every hour and a cacherev is generated once a week. There are a couple of useful scripts in the root directory, branch and merge which are described in the README.ARCH file. It is mirrored here: http://mirrors.sourcecontrol.net/mike@winehq.org--wine/ For your convenience, and for people who have never used arch before, here is an adapted form of the README file. It's available in pseudo-HTML here: http://navi.cx/~mike/wine/ ===================================================================== README.ARCH Mike Hearn <mike(a)navi.cx> GNU arch is a distributed source control system. Unlike CVS, arch trees can be branched and branched again with no write access to the original archive. It has a variety of other interesting features - for instance, it uses atomic commits and can operate using a variety of network protocols. For more information see http://wiki.gnuarch.org The rest of this readme is going to take the form of a tutorial on how to use arch with Wine. We'll start with the really basic tasks that even non-developers may wish to use, and work up to advanced usage (branching and merging). It will not answer every question you have, for that use the wine-devel mailing list for discussion :) * Tracking Wine development --------------------------- You might not be reading this file from an actual arch project tree, so let's start with how to get a copy of the gateway tree. First of all you need to install "tla", the reference implementation of arch. You can get it from the gnuarch.org website, but a simpler way is to use the prebuilt binary available here: http://www.navi.cx/~mike/wine/tla Download, chmod +x, copy to /usr/local/bin and you're set. The binary should work on any Linux distro. Yes, it's large, the arch build system contains local copies of various libraries. Now it's installed, run the following command: tla register-archive http://www.navi.cx/~mike/wine/archive/ Once it's registered succesfully (you get a message when that happens), you can run the following command to check out the tree: tla get mike(a)winehq.org--wine/wine--mainline--0.9 winehq This will place a copy of the gateway tree into the winehq/ directory. "winehq" is a good name to use, because you may later wish to download other branches or even make your own, but there will only ever be one WineHQ tree - the one controlled by Alexandre Julliard. Yes, I know mike(a)winehq.org isn't a valid email address, it doesn't matter, the email is only for namespacing and identification reasons :) The checkout will take a long time even on a fast link: the Wine sources are 10mb. Once downloaded, updating the tree is easy: tla update So, now you have an arch project tree, what can you do? Arch has a lot of interesting commands, try "tla changelog | less" and "tla missing -s". Have fun! * Simple development ==================== The easiest way to use arch for development is the same way we use CVS: by making changes in a tree, generating a diff from those changes, then emailing in the patch. Let's see how that works. First of all, we make a change to the tree. Then we use: tla changes --diffs to get a patch. In fact, this will generate a lot of extra stuff that you don't really need - feel free to remove it, but it's not required; patch can strip out garbage from patches automatically. You can get diffs for individual files with "tla file-diffs". Be warned! These commands work against the last revision you updated to, they do *not* work against the latest version in the remote archive like CVS does. So you probably want to update first. However, unlike people just tracking the tree, you DO NOT want to use update! What update does, roughly speaking, is reverse changes made to the tree, apply the missing patches in turn, then reapply the changes. If there are any conflicts they appear in patch style .rej and .orig files. There is a better way. Arch has a very interesting and powerful command called "star-merge". Star-merge allows you to merge your tree with another tree (subject to certain rules), in a Just Works(tm) fashion. It will deal with repeated merges, and it works if the person you are merging from previously merged with you. To make this simpler, I've written a script that figures out what you branched from (if anything), and then merges from it. In effect, this is like "cvs update". ./merge This operation can be quite slow (because it involves constructing multiple trees and comparing etc), but it is generic and will work both with the gateway tree and branches - and it gives 3-way merge inline conflict markers too. If you want to do it faster, and you don't mind having patch style .rej files generated in the case of conflicts, try: tla replay which simply downloads and applies each patch in turn. "tla update" does work too, why not try them all to see which you prefer? * More advanced development =========================== So, here comes the interesting part. Now we've covered the basics, it's time to find out how to make our own branches and commit to them. You need to do a bit of setup. Firstly, you need to tell arch who you are: tla my-id 'Mike Hearn <mike(a)navi.cx>' You have to use an ID of this form, arch won't accept others. Now you need to create your own archive. An archive is a rough equivalent of a CVS repository with one key, fundamental difference: an archive is a personal thing which can contain trees from many different projects. Typically a person has only one archive, though there's nothing to stop you having more. Archives are just directories and files, no special server software is required to run one. You just need some web space. The basic workflow with arch goes something like this: 1) Write patch 2) Commit to branch 3) Upload to a mirror of your archive Your actual archive is usually kept locally, which means you can work and commit offline. You then mirror the archive on a remote machine so others can access it. If people want to work on your tree, they branch it, set up their own archive and then you pull from that. In other words, only you have write access to your own archive. So, you need to create a directory to hold your archive, like this: tla make-archive mike(a)navi.cx--2004 ~/Code/Arch/2004 tla my-default-archive mike(a)navi.cx--2004 The named directory should not exist, but its parents should. An archive name must have the form of an email address followed by two dashes followed by a name. I've named it after the year of creation which is pretty common, but it can be called anything. Now, to speed things up, you probably want to create a revision library. This is basically a cache (using hard links to be space efficient) of revisions. You probably want it. Make one like this: mkdir ~/Code/Arch/RevLib tla my-revision-library ~/Code/Arch/RevLib tla library-config --sparse --greedy ~/Code/Arch/RevLib OK. Now you just need some web space. Arch can write to web space using ftp, sftp (ssh), or WebDAV. You probably want sftp. If you don't have any web space you can use talk to me and I'll put you in touch with people who can give you some space specifically for hosting archive mirrors. For now, don't bother with a remote mirror. Just play with a local copy, that way you can delete things if you make a mistake (you can delete a branch with rm -rf inside the archive, nothing will break). Let's say you wish to branch the WineHQ tree, and start work on the winecfg program. The simplest way to do this is to create a directory somewhere that you will keep all your wine trees in. I use /source/wine/arch. Then do this: tla get mike(a)winehq.org--wine/wine--mainline--0.9 winehq cd winehq ./branch winecfg The branch script is in the root of the gateway tree, and is written by me. It's designed to let you rapidly branch a given Wine tree. It works by "tagging" the new tree in arch, then duplicating the current tree using hard links before finally forcing the duplicate tree to the new branch. WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! WARNING! If you use the branch script you MUST use an editor that breaks hard links. emacs does by default, vim does if you :set bkc=no (though be warned, this will interfere with some programs that invoke vim like crontab -e). zile does not. If you want to use an editor that does not break hard links you must remove the -l option from cp in the branch script so a real duplicate is made. This uses more disk space and is slower to copy, but is safer. The result is a new directory called winecfg/ created as a sibling of the current directory. You can now commit to this tree however often you like. Running merge will update the branch from the tree you branched from (in this example, the gateway tree). You can branch from that tree again, and so on. Other people can branch from your tree in the same way! Feeling giddy with power yet? No? Good. Remember that patches which aren't in the mainline tree aren't reaching 99.9% of the users - being able to branch is useful but don't use it as an excuse to not get patches upstreamed! The new branch is put in the default archive and the name is derived from the current, for instance running branch in mike(a)winehq.org--wine/wine--mainline--0.9 with the parameter "winecfg" produces a branch with the name mike(a)navi.cx--2004/wine--winecfg--0.9 Now you need to publish a mirror: tla make-archive --mirror mike(a)navi.cx--2004 sftp://navi.cx/home/mike/public_html/archive and update it when you have done some commits tla archive-mirror which actually uploads the changes. If you are always connected, you can run the first make-archive command (back when you created your archive) with a remote location straight away, but doing it locally then mirroring is more common. Finally, tell people the URL of your archive so they can register it and grab your tree. That's it! Have fun! If you have any questions ask them on the wine-devel mailing list.

3 4

Ping: Gerald Pfeifer
by Dimitrie O. Paun 01 Apr '04

01 Apr '04

Hi Gerald, It seems nobody can send you email because: Recipient: <pfeifer(a)dbai.tuwien.ac.at> Reason: Service unavailable; Client host [fep03-mail.bloor.is.net.cable.rogers.com] blocked using abuse.rfc-ignorant.org; Not supporting abuse@domain; See http://www.dbai.tuwien.ac.at/block.html Nice, but that make the email account a bit useless, no? :) Anyway, I had a small question for you: what version of FreeBSD are you building Wine for? -- Dimi.

1 0

Re: shell32 patch 28
by Alexandre Julliard 01 Apr '04

01 Apr '04

"Martin Fuchs" <martin-fuchs(a)gmx.net> writes: > Changelog: > _ILCreateFolder(), _ILCreateValue(): check for NULL in AlternateFileName cAlternateFileName is an array, it cannot possibly be NULL. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: bug in winemine about box
by Ivan Leo Murray-Smith 01 Apr '04

01 Apr '04

> Are you really running a windows version of winemine under XP running in > Bochs? Or is the screen shot misleading? No, that is a windows build of winemine running on windows server 2003 (Got a 180 day trial license from M$, it's a free download), that is NOT windows xp. xp does run on bochs, but I don't have xp (Got some OEM cds with the pc(that I got for free), but trashed them as they were system restore cds and didn't run on bochs, and I didn't want dual boot), a few shots are at http://www003.portalis.it/115/win2k3/ Ivan.

1 0

Fwd: Developer's path to Windows/*NIX multi-platform?
by Sylvain Petreolle 01 Apr '04

01 Apr '04

You should write to wine-devel for that. ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) Say NO to software patents Dites NON aux brevets logiciels "You believe it's the year 1984, when in fact, its closer to 2184"1984 / Matrix Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Dialoguez en direct avec vos amis grâce à Yahoo! Messenger !Téléchargez Yahoo! Messenger sur http://fr.messenger.yahoo.com

1 0

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