Re: CHDIR/SetCurrentDirectory returns FILE_NOT_FOUND
[EMAIL PROTECTED] writes: > The installation routine of the ida dos disassembler (gg: ida37fw.zip), > wonn't work, because winedos/int21:0x3b CHDIR returns ERROR_FILE_NOT_FOUND. > If I return ERROR_PATH_NOT_FOUND it will install. > ntdll:RtlSetCurrentDirectory returns STATUS_OBJECT_NAME_NOT_FOUND, which gets > mapped to ERROR_FILE_NOT_FOUND (ntdll/error.c#L403). > > How to achieve the right behavior? > - Check for FILE_NOT_FOUND in winedos/int21.c: INT21_SetCurrentdirectory > - Check for FILE_NOT_FOUND in kernel/path.c: SetCurrentDirectoryW/A > - map STATUS_OBJECT_NAME_NOT_FOUND to ERROR_PATH_NOT_FOUND The bug is in int21.c. I committed a fix. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Wine on FreeBSD current
On Wed, Jun 16, 2004 at 07:49:26PM +0200, Gerald Pfeifer wrote: > >> I'm just wondering if it is supposed to work as well as FreeBSD stable. > > Right now, Wine doesn't work at all on FreeBSD -STABLE: > > wine: failed to initialize: /swtest/wine/dlls/ntdll.dll.so: mmap of > entire address space failed: Cannot allocate memory > > and before that I used to see deadlocks upon startup of non-trivial > applications (such as Forte Agent, both 16bit and 32bit flavors). > > I believe there are also signficant threadings issues on -CURRENT, so > overall Wine is hardly, if at all, usable on any version of FreeBSD I > have access to, even though I'm still working to keep it at least > compilable on FreeBSD 4.9 and 5.2/5.3. Hi Gerald, Thanks for the reply. >From what I can see, there are two problems with the Wine build from CVS on FreeBSD -current that seem to be related to the use of BSD make. In the dlls 'setupapi' and 'version' directories there are source files called install.c. These confuse the build during a "make install". BSD make tries to compile and link a program called "install". Renaming the source files to something other than install.c (such as winstall.c) allows the build to succeed. At run time, the error: "wine: failed to initialize: /something/lib/wine/ntdll.dll.so: mmap of entire address space failed: Cannot allocate memory" is caused by Wine attempting to mmap memory outside the user process address space. I see mmap addr around 0xd810 (mostly 0xd81eccd8) whereas the user address space limit on FreeBSD current is 0xbfc0 (at least on my system). This failure is well before any thread library issues are encountered. I ran a test of mmap on FreeBSD current to see what address space I was able to mmap. Using objdump to identify the pages that the test program was linked to load in, the test program was able to mmap MAP_ANON, MAP_FIXED, MAP_NOCORE all memory from 0x0 to 0xbfc0, except the pages at which the test program was mapped at. I'll look further into how Wine is mmap'ing memory on FreeBSD. -- John Birrell
Re: wine window disappears from virtual desktop!
Paul R Streitman <[EMAIL PROTECTED]> writes:
> Last week, I appended about this problem: Application windows under wine
> disappear if you switch to a different virtual desktop and then back under
> either AfterStep or Enlightenment window managers. The program is still
> apparently running (according to top), but there is no way to retrieve it
> and it no longer appears in the window manager's window list. It has to be
> killed off and restarted.
Does this help?
Index: dlls/x11drv/winpos.c
===
RCS file: /opt/cvs-commit/wine/dlls/x11drv/winpos.c,v
retrieving revision 1.85
diff -u -p -r1.85 winpos.c
--- dlls/x11drv/winpos.c14 Jun 2004 19:32:21 - 1.85
+++ dlls/x11drv/winpos.c17 Jun 2004 03:19:19 -
@@ -1014,7 +1014,7 @@ BOOL X11DRV_SetWindowPos( WINDOWPOS *win
RDW_NOERASE | RDW_NOINTERNALPAINT | RDW_ALLCHILDREN );
set_visible_style( winpos->hwnd, FALSE );
}
-else if ((wndPtr->dwStyle & WS_VISIBLE) &&
+else if ((wndPtr->dwStyle & WS_VISIBLE) && bChangePos &&
X11DRV_is_window_rect_mapped( &oldWindowRect ) &&
!X11DRV_is_window_rect_mapped( &newWindowRect ))
{
@@ -1046,7 +1046,7 @@ BOOL X11DRV_SetWindowPos( WINDOWPOS *win
{
set_visible_style( winpos->hwnd, TRUE );
}
-else if ((wndPtr->dwStyle & WS_VISIBLE) &&
+else if ((wndPtr->dwStyle & WS_VISIBLE) && bChangePos &&
!X11DRV_is_window_rect_mapped( &oldWindowRect ) &&
X11DRV_is_window_rect_mapped( &newWindowRect ))
{
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: D3D9 - Anyone working on that
> Is anyone working on DX9? > It's all implemented by stubs right now, and I was thinking of lending > a hand. If anyone's doing that, do you have a place where I can see how > far you've gotten. If you want to start working on this, better ask Raphael, Jason and Christian first (as I suppose that they have a tree a bit more advanced than what is committed to the current WineHQ tree). Moreover, if you had read my interview ( :-) ), you would have seen that the plan (dictated by Raphael, the author of the DX9 stubs) is to first create the wined3d 'low level driver' to be able to layer both the DX8 and DX9 code over it (to prevent HUGE code duplication). Note that if you prod enough, maybe he will actually work on it ;-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
D3D9 - Anyone working on that
Hey, Is anyone working on DX9? It's all implemented by stubs right now, and I was thinking of lending a hand. If anyone's doing that, do you have a place where I can see how far you've gotten. No point in reinventing the wheel. I probably won't be able to do very advanced work with it because I've barely touched DX under Windows, I can find a few books on it though. Also I've never used DX shaders, only CG so unless it's very close to that I can't much help there, I am willing to try though. If noone's in the middle of doing that, I guess I can start on my own. Thanks, Andrei signature.asc Description: This is a digitally signed message part
Re: dlls/dinput/mouse.c warp handling
> this is a more complete version of my mouse patch in which I tried to > remove this funny mouse-warping-stuff. > > the mouse feels much better this way, but I am new to wine and maybe I > missed something important and/or did not remove the mousewarping cleanly. Errrm, do you understand exactly what you remove and why it was in the code ? Basically, if you remove mouse warping, when you play games like Quake, you will only be able to turn to your right (or left :-) ) for a fixed amount... I.e. up until the point where the mouse will hit the right border of the window. I agree though that 2D games (like StarCraft or others) will feel a LOT better with a patch like that, but it's plainly wrong. The only way to fix this is to sometimes warp the mouse back in the middle of the window (or to use DGAMouse (or to write a new X11 extension :-) )). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: dlls/dinput/mouse.c - GetDeviceState
> this patch adds a missing errorcode in GetDeviceState in > dlls/dinput/mouse.c which prevented the mouse to work in some game. Which games did require this error to be set ? I seem to remember some hacks around this but I do not remember if it was an error added in the GetDeviceData function or an error removed somewhere because it relied on getting something even if not acquired... I will try a test application when I have access to my Windows development machine to get the error code :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
wine window disappears from virtual desktop!
Last week, I appended about this problem: Application windows under wine disappear if you switch to a different virtual desktop and then back under either AfterStep or Enlightenment window managers. The program is still apparently running (according to top), but there is no way to retrieve it and it no longer appears in the window manager's window list. It has to be killed off and restarted. I have now isolated the problem to the change made to wine/dlls/x11drv/winpos.c in patch http://cvs.winehq.org/patch.py?id=12173 on 4/27/2004. I do not know enough to take it further. For what it is worth, today's cvs wine with a 4/26 version of winpos.c seems to work just fine. Thanks, Paul z/OS core components development Internet: [EMAIL PROTECTED]
Re: Wine on FreeBSD current
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 16 June 2004 13:19, Gerald Pfeifer wrote: > > Given that I'm the maintainer of the wine port in FreeBSD, I can say > quite authoritatively that I probably won't update to the latest snapshot, > unless some third party is able to provide a patch to fix this breakage. > I tried to look through the mmap.c code but I don't have enough of an understanding of what it is supposed to do to figure out how to make it work, or even work around it. - -- Jonathan Fosburgh AIX and Storage Administrator UT MD Anderson Cancer Center Houston, TX -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFA0JdxqUvQmqp7omYRAkQJAJ9MGV4Z/lVYw1WOw7YL01BgLQ+QRQCfbF6P gKjb73HptvibzRDRqmsy8B0= =dpxK -END PGP SIGNATURE-
Re: Wine on FreeBSD current
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 16 June 2004 12:49, Gerald Pfeifer wrote: > >> I'm just wondering if it is supposed to work as well as FreeBSD stable. > > Right now, Wine doesn't work at all on FreeBSD -STABLE: > > wine: failed to initialize: /swtest/wine/dlls/ntdll.dll.so: mmap of > entire address space failed: Cannot allocate memory > I get the same problem on -CURRENT with recent CVS versions of wine. Hopefully, in the port of the new release, this will bee worked out and maybe I can stick with the port and not mess with CVS. - -- Jonathan Fosburgh AIX and Storage Administrator UT MD Anderson Cancer Center Houston, TX -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFA0Io4qUvQmqp7omYRAjroAKCy/HQJ2y3Y9Y8n7rRoS8yqkxNozwCfZfcP OpleJ+reEedjRT3o3UDzr6Y= =/tbJ -END PGP SIGNATURE-
Re: WineHQ-hosted projects?
Quoting Rick Romero <[EMAIL PROTECTED]>: > How about using AppDB? http://appdb.winehq.com/ > > Open a couple bug reports, and use AppDB as your central starting > point... it's not really designed to be a weblog in that sense > (monitoring bug status for a specific app), but maybe you could work > with Jeremy to enhance that ;) > > Or maybe tie AppDB to bugzilla? Have a link to bugzilla for all bugs > for "this" application? Hmm, that's a good idea. It'd have to extend the current AppDB quite a lot, but it might be worth a try. Maybe a "bugs that effect this app" thing (like you said), and a more powerful forum system to coordinate efforts. I'll check into it. Jeremy? You listening? Maybe I'll track him down and see what I can do. -- Joel Konkle-Parker Webmaster [Ballsome.com] E-mail [EMAIL PROTECTED] Phone [662-518-1636]
Re: WineHQ-hosted projects?
On Wed, 2004-06-16 at 04:51, Joel Konkle-Parker wrote: > Quoting Mike Hearn <[EMAIL PROTECTED]>: > > Could you explain more about such a project? If you're going to be fixing > > bugs for a specific app it's probably best to just co-ordinate using > > wine-devel, that way if you run into problems far more people will see and > > be able to help. > > Sure. > > My goal in starting up such a project would just be to provide a place and a > means to coordinate efforts toward a specific goal for people who care about > such a goal. There's a huge Star Wars Galaxies fan base out there, and a large > number of people who would like to see this on WINE. A website devoted to the > goal of making SWG work on WINE would provide a focus for that group of people. How about using AppDB? http://appdb.winehq.com/ Open a couple bug reports, and use AppDB as your central starting point... it's not really designed to be a weblog in that sense (monitoring bug status for a specific app), but maybe you could work with Jeremy to enhance that ;) Or maybe tie AppDB to bugzilla? Have a link to bugzilla for all bugs for "this" application? Rick -- -- Rick Romero IT Manager Valeo, Inc. ph: 262.695.4841 Sussex, WI. fax: 262.695.4850 [EMAIL PROTECTED]
Re: [ILLUSTRATOR10] not installable, need to merge 'winedefault.reg'
On Wed, 2004-06-16 at 16:32, Luca Capello wrote: > ERROR: You need to merge the 'winedefault.reg' file into your >Wine registry by running: `regedit winedefault.reg' > > fixme:ole:_LocalServerThread CoMarshalInterface failed, 80070057! > > ERROR: You need to merge the 'winedefault.reg' file into your >Wine registry by running: `regedit winedefault.reg' > > fixme:ole:_LocalServerThread CoMarshalInterface failed, 80070057! > [EMAIL PROTECTED]:~$ > = > > But where I can find 'winedefault.reg' in the released 'wine-20040615'? You should run "regsvr32 ole32" instead. You may also need to run "regsvr32 oleaut32". Rob
Re: [PHOTOSHOP7] not installable, OS not supported, for NT4 service pack >= 6a
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Mike, on 06/16/04 15:58, Mike Hearn wrote: > On Wed, 16 Jun 2004 12:33:29 +0200, Luca Capello wrote: >> 'Adobe Photoshop 7.0' can't be installed: the problem is grave, as the >> installation process doesn't start at all. > This is probably because we default to using DLL linkage heuristics in the > no config file case. These are frequently wrong, most people just set > their config file to default to Win98. I sent a patch to create a new > "auto" version to restore the old behaviour and set the default version to > 98, does it help? yes, I had seen your patch but I didn't have time to test. Now I did and it solve the problem, Photoshop 7.0 installs correctly (just the 'cannot create shourcut set' or something similar, but this isn't a problem at all, just a minor bug). Thx, bye, Gismo / Luca -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFA0HHxVAp7Xm10JmkRAo+EAJ9/FCBlHJi5/F10h5B/csWYoElxrgCdFVK3 ir4zOm0Kt8OmAiUPvv1wL9Q= =J4C8 -END PGP SIGNATURE-
Re: WineHQ-hosted projects?
Quoting Mike Hearn <[EMAIL PROTECTED]>: > Could you explain more about such a project? If you're going to be fixing > bugs for a specific app it's probably best to just co-ordinate using > wine-devel, that way if you run into problems far more people will see and > be able to help. Sure. My goal in starting up such a project would just be to provide a place and a means to coordinate efforts toward a specific goal for people who care about such a goal. There's a huge Star Wars Galaxies fan base out there, and a large number of people who would like to see this on WINE. A website devoted to the goal of making SWG work on WINE would provide a focus for that group of people. It'd probably just consist of a website and a forum of some kind to track in greater detail what's changing and what needs to be changed that would effect SWG. "Heads up, bug #x needs to get fixed for the launcher to work", "Ok guys, if you want get the in-game browser working, we all need to put our efforts into IE", etc. I'm not talking about forked codebases here, just a place with a more guided focus on a specific WINE goal. I guess SF.net would be a good place to start, or maybe a personal blog. -- Joel Konkle-Parker Webmaster [Ballsome.com] E-mail [EMAIL PROTECTED] Phone [662-518-1636]
[ILLUSTRATOR10] not installable, need to merge 'winedefault.reg'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, as reported in my previous mail, after the trick for DCOM95, 'Adobe Illustrator 10' is still not installable, cause this error: = [EMAIL PROTECTED]:~$ wine win32_install/Adobe/Adobe.Illustrator.10/Adobe\ Illustrator\ 10/Setup.exe fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects ERROR: You need to merge the 'winedefault.reg' file into your Wine registry by running: `regedit winedefault.reg' fixme:ole:_LocalServerThread CoMarshalInterface failed, 80070057! ERROR: You need to merge the 'win
Device drivers in Wine
Hi Basically, I have a Windows user-space device driver, and I need to get it working under Linux. I note Wine has some "device" functions (FILE_CreateDevice(), and DOSFS_OpenDevice()). How do these work and what do they do? Are they documented anywhere? And is there a way to open and use a Windows DLL from a Linux program? Thanks Damjan __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail
Re: PATCH: fix dlls/ntdll/cdrom.c breakage
> "Gerald" == Gerald Pfeifer <[EMAIL PROTECTED]> writes:
Gerald> The following patch to dlls/ntdll/cdrom.c revision 1.46 date:
Gerald> 2004/06/15 00:45:01; author: julliard; state: Exp; lines: +421
Gerald> -1 Uwe Bonnes <[EMAIL PROTECTED]> Support
Gerald> for reading encrypted DVDs.
Gerald> causes a build failure on all FreeBSD (and it seems also NetBSD)
Gerald> platforms:
Gerald> cdrom.c: In function `DVD_EndSession': cdrom.c:1739: error:
Gerald> `dev' undeclared (first use in this function) cdrom.c:1739:
Gerald> error: (Each undeclared identifier is reported only once
Gerald> cdrom.c:1739: error: for each function it appears in.)
Gerald> cdrom.c:1739: error: `rmv' undeclared (first use in this
Gerald> function) gmake[2]: *** [cdrom.o] Error 1 gmake[2]: Leaving
Gerald> directory `/.amd_mnt/nashira/files5/test/wine/dlls/ntdll'
Gerald> gmake[1]: *** [ntdll] Error 2
Gerald> There is BSD-specific code in this function, but both dev and
Gerald> rmv do not appear anywhere, so I guess this was copied from
Gerald> somewhere else and then not adjusted?
The Non-Linux side of the patch was never tested. Appended patch return
STATUS_NOT_SUPPORTED for that code clause and should make the code compile
again.
Gerald, can you perhaps have a look at the implementation of the BSD parts?
libdvdcss should have all the needed calls somewhere.
Bye
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
- Tel. 06151 162516 Fax. 06151 164321 --
Index: wine/dlls/ntdll/cdrom.c
===
RCS file: /home/wine/wine/dlls/ntdll/cdrom.c,v
retrieving revision 1.46
diff -u -w -r1.46 cdrom.c
--- wine/dlls/ntdll/cdrom.c 15 Jun 2004 00:45:01 - 1.46
+++ wine/dlls/ntdll/cdrom.c 16 Jun 2004 15:11:00 -
@@ -1736,7 +1736,8 @@
TRACE("\n");
return CDROM_GetStatusCode(ioctl(fd, DVD_AUTH, &auth_info));
#elif defined(__FreeBSD__) || defined(__NetBSD__)
-return CDROM_GetStatusCode(ioctl(cdrom_cache[dev].fd, (rmv->PreventMediaRemoval)
? CDIOCPREVENT : CDIOCALLOW, NULL));
+TRACE("bsd\n");
+return STATUS_NOT_SUPPORTED;
#else
return STATUS_NOT_SUPPORTED;
#endif
Re: [DCOM95] not installable: "a newer version had been installed"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello again, on 06/16/04 16:46, Mike Hearn wrote: > On Wed, 16 Jun 2004 16:21:22 +0200, Luca Capello wrote: >> This does the trick for both DCOM95 and DCOM98 (as in the reported >> logs). First, I got a message to debug a problem >> = >> fixme:seh:EXC_RtlRaiseException call to unimplemented function >> shell32.dll.SHGetSpecialFolderPathW >> wine: Unhandled exception (thread 0009), starting debugger... >> = > Well this is very strange, this function is definitely implemented in > Wine. Try using > > WINEDLLOVERRIDES="ole32=n,shell32=b" wine DCOM95.EXE > > does that help? no, same problem. BTW, I found another minor problem: the TMP folder created by DCOM95 isn't deleted at the end of the installation. You can see the log in the attached file. The same occurs for DCOM98. > No, this list is fine. I'll try and fix the simpler problems as we go. > Of course, I'm not sure I should put too much effort into this as soon > the config file will "reappear" but in the registry :) Ok, thank you for your efforts. I'll continue report bugs with the 'no-config' environment. > I meant the #winehq channel FAQ I (badly) maintain. See here: > > http://bylands.dur.ac.uk/~mh/wine-faq.html > > I guess this should be linked to from winehq really, it is more about > specific problems with specific apps than the official FAQ which is > more general. Sorry, my mistake. And I agree, it should be linked from WineHQ (as I don't see any other way to fall on your #winehq channel FAQ. Thx, bye, Gismo / Luca -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFA0GLuVAp7Xm10JmkRAiK+AJ0fiPuc4nVpw4n+MvJnFo56JswepgCeM6Eo /U7OTHnwDlI7CRfMh3MNETo= =gcbG -END PGP SIGNATURE- test-dcom-tmp.log.gz Description: GNU Zip compressed data
Re: WineHQ-hosted projects?
No need to fork winehq to support such things. Imaging having to keep up with all of the patches applied to the mainline code? It's probably better just to fix things that break those apps in the winehq tree so every other app gets the benifit. Chris > > From: Joel Konkle-Parker <[EMAIL PROTECTED]> > Date: 2004/06/16 Wed AM 07:09:28 EDT > To: [EMAIL PROTECTED] > Subject: WineHQ-hosted projects? > > I'd like to start up a WINE-based project to further development for a > specific app. (e.g. The WINE-Star Wars Galaxies Project, or The > WINE-Internet Explorer Project). Does WineHQ have a place to host such > things (with their own sites, etc.), or should I turn to SourceForge? > > > -- > Joel Konkle-Parker > Webmaster [Ballsome.com] > > E-mail [EMAIL PROTECTED] > > >
WineHQ-hosted projects?
I'd like to start up a WINE-based project to further development for a specific app. (e.g. The WINE-Star Wars Galaxies Project, or The WINE-Internet Explorer Project). Does WineHQ have a place to host such things (with their own sites, etc.), or should I turn to SourceForge? -- Joel Konkle-Parker Webmaster [Ballsome.com] E-mail [EMAIL PROTECTED]
(no subject)
The following patch to dlls/shell32/shlexec.c revision 1.50 date: 2004/06/15 00:44:14; author: julliard; state: Exp; lines: +11 -3 Dmitry Timoshkov <[EMAIL PROTECTED]> Restore default "open" functionality of ShellExecute. introduced the following warning regressions: shlexec.c:722: warning: format argument is not a pointer (arg 11) shlexec.c:722: warning: format argument is not a pointer (arg 12) Would you mind fixing this? Gerald -- Gerald Pfeifer (Jerry) [EMAIL PROTECTED] http://www.pfeifer.com/gerald/
How to test patches?
I want to patch something in wrc/ (hopefully trivial), but I'm not sure how to test for any side effects. Is there a regression test suite or something you guys use to test your patches? Thanks. -- Joel Konkle-Parker Webmaster [Ballsome.com] E-mail [EMAIL PROTECTED]
Re: [DCOM95] not installable: "a newer version had been installed"
On Wed, 16 Jun 2004 16:21:22 +0200, Luca Capello wrote: > This does the trick for both DCOM95 and DCOM98 (as in the reported > logs). First, I got a message to debug a problem > = > fixme:seh:EXC_RtlRaiseException call to unimplemented function > shell32.dll.SHGetSpecialFolderPathW > wine: Unhandled exception (thread 0009), starting debugger... > = Well this is very strange, this function is definitely implemented in Wine. Try using WINEDLLOVERRIDES="ole32=n,shell32=b" wine DCOM95.EXE does that help? > BTW, I supposed 'wine-devel' to be a better place than 'wine-user' to > report these problems becuase I'm making these tests after Mike's > question about 'wineinstall'. Please let me know if I should switch to > 'wine-user'. No, this list is fine. I'll try and fix the simpler problems as we go. Of course, I'm not sure I should put too much effort into this as soon the config file will "reappear" but in the registry :) > Mmm, I can't find any hit for 'winedll' or 'dcom' in the WineHQ FAQ [1]. I meant the #winehq channel FAQ I (badly) maintain. See here: http://bylands.dur.ac.uk/~mh/wine-faq.html I guess this should be linked to from winehq really, it is more about specific problems with specific apps than the official FAQ which is more general. thanks -mike
Re: [DCOM95] not installable: "a newer version had been installed"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Mike, on 06/16/04 14:57, Mike Hearn wrote: > On Wed, 16 Jun 2004 12:09:29 +0200, Luca Capello wrote: >> This is the first test of two: 'Adobe Illustrator 10' doesn't install >> because a problem with the DCOM95 package > Yes, the InstallShield/DCOM problems are well known. Me and Rob have > started looking at this in the last few days, hopefully we'll have > progress to report soon. ok, nice to hear that someone is working on it. > You have to run it like this: > > WINEDLLOVERRIDES="ole32=n" wine DCOM95.exe > > Yes, this is unintuitive, no there is nothing we can do with default > config files/registry entries to fix it as the first thing DCOM95.EXE > does it extract a file called "setup.exe" or some equally generic name > and run it. You have to love Windows installers. This does the trick for both DCOM95 and DCOM98 (as in the reported logs). First, I got a message to debug a problem = fixme:seh:EXC_RtlRaiseException call to unimplemented function shell32.dll.SHGetSpecialFolderPathW wine: Unhandled exception (thread 0009), starting debugger... = but after the debug step I could continue installing DCOM95/DCOM98 without the previous problem. Well, now I got another error for 'Adobe Illustrator 10', but I'll report it in a new thread. BTW, I supposed 'wine-devel' to be a better place than 'wine-user' to report these problems becuase I'm making these tests after Mike's question about 'wineinstall'. Please let me know if I should switch to 'wine-user'. > WineTools basically sets up a fake C drive (same as our own > wineprefixcreate) and then fills it with a ton of native DLLs. It's a > solution you can use if you like, though the real fix is just to nail > DCOM so it works out of the box. Yes, I know the native DLLs of 'WineTools' :-) I've no preference for the WineTools' fake_windows or the Wine one: actually, if I could use the Wine one it'll be better, so the reason of my tests. >> Is this the same problem reported as bug #1456 [4]? Or is it a problem >> of mine? > Yes, it's the same problem but that bug is old and can be closed. I > changed email addresses and no longer have full access rights to the > WineHQ bugzilla so I can't do this myself. Originally I thought by > modifying the ole32 DLL version we could make it install but that's a > catch-22 situation: modifying the version to allow it to be upgraded > just stops other apps working because the DLL appears too old. The > environment variable "fix" works, but isn't well known. It's in the > #winehq FAQ but that's it, AFAIK. Mmm, I can't find any hit for 'winedll' or 'dcom' in the WineHQ FAQ [1]. Thx, bye, Gismo / Luca [1] http://www.winehq.com/site/docs/wine-faq/index -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFA0FdgVAp7Xm10JmkRAgdTAJ99M+kqFEqy+ydHKKjBxY5h4lidXQCcCUpg cVapiWVoDDJXru6uXKsp/pI= =JDOd -END PGP SIGNATURE- wine-20040615_DCOM95.log.gz Description: GNU Zip compressed data wine-20040615_DCOM98.log.gz Description: GNU Zip compressed data
Re: [DCOM95] not installable: "a newer version had been installed"
On Wed, 16 Jun 2004, Mike Hearn wrote: > On Wed, 16 Jun 2004 12:09:29 +0200, Luca Capello wrote: > > "A newer version of DCOM95 or DCOM98 had been installed. To override, > > you must uninstall the current version first." > > You have to run it like this: > > WINEDLLOVERRIDES="ole32=n" wine DCOM95.exe > > Yes, this is unintuitive, no there is nothing we can do with default > config files/registry entries to fix it as the first thing DCOM95.EXE does > it extract a file called "setup.exe" or some equally generic name and run > it. You have to love Windows installers. And why there couldn't be additional option introduced for AppDefaults sections to instruct Wine to apply AppDefaults for child processes too? If we cannot fix the situation by using the win32-process name, maybe the situation would be easier to fix if we'd using the name of its parent win32-process or even name of the its first ancestor win32-process? Lets name the option "ChildProcessInheritsAppDefaults", for example. How hard it would be to implement such parent-to-child option replication?
Re: [PHOTOSHOP7] not installable, OS not supported, for NT4 service pack >= 6a
On Wed, 16 Jun 2004 12:33:29 +0200, Luca Capello wrote: > 'Adobe Photoshop 7.0' can't be installed: the problem is grave, as the > installation process doesn't start at all. This is probably because we default to using DLL linkage heuristics in the no config file case. These are frequently wrong, most people just set their config file to default to Win98. I sent a patch to create a new "auto" version to restore the old behaviour and set the default version to 98, does it help?
Re: WineHQ-hosted projects?
On Wed, 16 Jun 2004 07:09:28 -0400, Joel Konkle-Parker wrote: > I'd like to start up a WINE-based project to further development for a > specific app. (e.g. The WINE-Star Wars Galaxies Project, or The > WINE-Internet Explorer Project). Does WineHQ have a place to host such > things (with their own sites, etc.), or should I turn to SourceForge? Could you explain more about such a project? If you're going to be fixing bugs for a specific app it's probably best to just co-ordinate using wine-devel, that way if you run into problems far more people will see and be able to help. thanks -mik
Re: WineHQ-hosted projects?
On Wed, Jun 16, 2004 at 07:09:28AM -0400, Joel Konkle-Parker wrote: > I'd like to start up a WINE-based project to further development for a > specific app. (e.g. The WINE-Star Wars Galaxies Project, or The > WINE-Internet Explorer Project). Does WineHQ have a place to host such > things (with their own sites, etc.), or should I turn to SourceForge? WineHQ does not host other projects ATM, SourceForge is the way to go. -- Dimi.
Re: [DCOM95] not installable: "a newer version had been installed"
On Wed, 16 Jun 2004 12:09:29 +0200, Luca Capello wrote: > This is the first test of two: 'Adobe Illustrator 10' doesn't install > because a problem with the DCOM95 package Yes, the InstallShield/DCOM problems are well known. Me and Rob have started looking at this in the last few days, hopefully we'll have progress to report soon. > I downloaded the DCOM95 package [2], but when I tried to install it, I > got the message window: > "A newer version of DCOM95 or DCOM98 had been installed. To override, > you must uninstall the current version first." You have to run it like this: WINEDLLOVERRIDES="ole32=n" wine DCOM95.exe Yes, this is unintuitive, no there is nothing we can do with default config files/registry entries to fix it as the first thing DCOM95.EXE does it extract a file called "setup.exe" or some equally generic name and run it. You have to love Windows installers. > The same if I try to install DCOM98... and I can't install 'Adobe > Illustrator 10' :-( > > With the 'fake_windows' provided by the 'WineTools' [3], I can install > the DCOM98 with no problem. WineTools basically sets up a fake C drive (same as our own wineprefixcreate) and then fills it with a ton of native DLLs. It's a solution you can use if you like, though the real fix is just to nail DCOM so it works out of the box. > Is this the same problem reported as bug #1456 [4]? Or is it a problem > of mine? Yes, it's the same problem but that bug is old and can be closed. I changed email addresses and no longer have full access rights to the WineHQ bugzilla so I can't do this myself. Originally I thought by modifying the ole32 DLL version we could make it install but that's a catch-22 situation: modifying the version to allow it to be upgraded just stops other apps working because the DLL appears too old. The environment variable "fix" works, but isn't well known. It's in the #winehq FAQ but that's it, AFAIK. thanks -mike
WineHQ-hosted projects?
I'd like to start up a WINE-based project to further development for a specific app. (e.g. The WINE-Star Wars Galaxies Project, or The WINE-Internet Explorer Project). Does WineHQ have a place to host such things (with their own sites, etc.), or should I turn to SourceForge? -- Joel Konkle-Parker Webmaster [Ballsome.com] E-mail [EMAIL PROTECTED] begin:vcard fn:Joel Konkle-Parker n:Konkle-Parker;Joel email;internet:[EMAIL PROTECTED] version:2.1 end:vcard
[PHOTOSHOP7] not installable, OS not supported, for NT4 service pack >= 6a
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, this is the second test with no config file as Mike Hearn suggested [1]. 'Adobe Photoshop 7.0' can't be installed: the problem is grave, as the installation process doesn't start at all. The steps: = [EMAIL PROTECTED]:~/cvs/wine-20040615$ rm -rf /home/luca/.wine/ [EMAIL PROTECTED]:~/cvs/wine-20040615$ wine /home/luca/win32_install/Adobe/Adobe.Photoshop.7/Photoshop/Setup.exe wine: creating configuration directory '/home/luca/.wine'... wine: '/home/luca/.wine' created successfully. fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet. [EMAIL PROTECTED]:~/cvs/wine-20040615$ = I can see the 'Photoshop 7' logo window, but then another window appears with this message: "This operating system is not supported by this installation. For Windows NT 4, you must have service pack 6a or greater to install. Setup will now quit." And pressing OK causes nothing, I mean, I don't need to press OK to have 'wine' quitting: I can leave the message window open and continue to use the 'gnome-terminal' with no problem. Again, with the 'fake_windows' provided by the 'WineTools' [2], I can install 'Photoshop 7.0' with all the options (included 'ImageReady'). The only problem I get is an error creating the icon set, but pressing 'OK' lets the installation process to finish cleanly. Solutions? Thx, bye, Gismo / Luca [1] http://www.winehq.org/hypermail/wine-devel/2004/06/0242.html [2] http://franksworld.net/winetools.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFA0CH4VAp7Xm10JmkRAmufAJ9yKlSlSJhV6Wt0C1RIYGdoacLsxgCfUi1B /bN09F/mXRzMmG5lKTqDQss= =ARER -END PGP SIGNATURE-
[DCOM95] not installable: "a newer version had been installed"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, as Mike Hearn asked if 'wineinstall' is still needed [1], I was making some tests with no config file and a fresh 'fake_windows' created automatically by 'wine-20040615'. This is the first test of two: 'Adobe Illustrator 10' doesn't install because a problem with the DCOM95 package The steps: - - get and uncompress 'Wine-20040615' - - ./configure && make depend && make - - su root - - make install - - CTRL-D - - then the following = [EMAIL PROTECTED]:~/cvs/wine-20040615$ wine /home/luca/win32_install/Adobe/Adobe.Illustrator.10/Adobe\ Illustrator\ 10/Setup.exe wine: creating configuration directory '/home/luca/.wine'... wine: '/home/luca/.wine' created successfully. fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy
