Re: Dereferencing a pointer in winedbg
http://www.winehq.org/hypermail/wine-devel/2005/03/0219.html (not sure it still applies cleanly, at least some tiny parts are now in CVS tree)A+ > Message du 30/11/05 05:13> De : "Vitaliy Margolen" <[EMAIL PROTECTED]>> A : "Eric Pouech" <[EMAIL PROTECTED]>> Copie à : wine-devel@winehq.org> Objet : Re: Dereferencing a pointer in winedbg> > Monday, November 28, 2005, 2:33:35 PM, Eric Pouech wrote:> > Vitaliy Margolen wrote:> >> Sunday, November 27, 2005, 10:50:39 PM, Marcus Meissner wrote:> >> > >>>On Sun, Nov 27, 2005 at 06:35:15PM -0700, Vitaliy Margolen wrote:> Is it possible to dereference a pointer in winedbg? Help says that> "*$eax" is a valid _expression_. But when I'm trying to use it it saying:> Wine-dbg>p *$eax> No type or type mismatch> > Is there are a way to do this?> >>>(x aka examine memory)> >>>x $eax> >>>Ciao, Marcus> >> > >> > >> Well I need to add that to display. Something like: display/x *$eax> >> Doing x $eax and then x 100s times kind of hard.> > > display /x means (in gdb) formatting differently the output, not > > dereferencing the (so called) pointer (display is a repeated 'p' > > command, not a 'x' one).> Yes I know. I meant /x for hex not decimal.> > > what you'd need is support for type casts and use something like:> > display *(int*)$eax> Yes correct. That's exactly what I need.> > > I sent a couple of months ago a patch for winedbg that (partly) > > implemented the support for typecasts in wine. You should look for it.> Could you please point me to it? I've spent last hour or so trying to> find it.> > Vitaliy.> > > > > > > > >
Re: [wined3d] update hw support
On Wed, Nov 30, 2005 at 07:56:54AM +0100, Roderick Colenbrander wrote: > The way I would recommend for pci bus scanning is to parse > /proc/bus/pci/devices the only problem is that this is linux specific. > Something similar can be done on other OSes though. Another way which is > more portable is to use libpci but it isn't installed on all systems. Guess > something like this would need to be added to some 'kernel' dll... Better use libsysfs or /sys/ directly if you do that. Ciao, Marcus
Re: [wined3d] update hw support
The way I would recommend for pci bus scanning is to parse /proc/bus/pci/devices the only problem is that this is linux specific. Something similar can be done on other OSes though. Another way which is more portable is to use libpci but it isn't installed on all systems. Guess something like this would need to be added to some 'kernel' dll... Roderick > > PS: if one of you know a way to implement pci bus scanning on wine i'll be > happy > -- 10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail +++ GMX - die erste Adresse für Mail, Message, More +++
riched20: register ListBox & ComboBox classes
Hi, > This patch partially implements the undocumented REExtendedRegisterClass() > function by registering the two missing classes. That way MS Office 2003 and > probably other programs that rely on these classes display dialogs > completely which were empty before. > > Changelog: > Cihan Altinay <[EMAIL PROTECTED]> > Partially implement REExtendedRegisterClass() to register missing window > classes so that applications relying on them don't get confused. > It seems this patch was ignored and I would appreciate some comments because I haven't done much wine development yet (and probably made a lot of mistakes). Basically, I did some reverse engineering to see what is going on under Windows and implemented the (de)registration of the two classes accordingly. The effect of the patch can be seen in the attached screenshots which is the Options dialog of MS PowerPoint 2003. I agree that a patch that makes the controls actually work would be better :-) Cheers, Cihan dlg_after_patch.png Description: PNG image dlg_before_patch.png Description: PNG image
Re: Dereferencing a pointer in winedbg
Monday, November 28, 2005, 2:33:35 PM, Eric Pouech wrote: > Vitaliy Margolen wrote: >> Sunday, November 27, 2005, 10:50:39 PM, Marcus Meissner wrote: >> >>>On Sun, Nov 27, 2005 at 06:35:15PM -0700, Vitaliy Margolen wrote: >>> Is it possible to dereference a pointer in winedbg? Help says that "*$eax" is a valid expression. But when I'm trying to use it it saying: Wine-dbg>p *$eax No type or type mismatch Is there are a way to do this? >>> >>>(x aka examine memory) >>> >>>x $eax >>> >>>Ciao, Marcus >> >> >> Well I need to add that to display. Something like: display/x *$eax >> Doing x $eax and then x 100s times kind of hard. > display /x means (in gdb) formatting differently the output, not > dereferencing the (so called) pointer (display is a repeated 'p' > command, not a 'x' one). Yes I know. I meant /x for hex not decimal. > what you'd need is support for type casts and use something like: > display *(int*)$eax Yes correct. That's exactly what I need. > I sent a couple of months ago a patch for winedbg that (partly) > implemented the support for typecasts in wine. You should look for it. Could you please point me to it? I've spent last hour or so trying to find it. Vitaliy.
Re: Question about X11DRV_ChoosePixelFormatglXChooseFBConfig returns NULL (glError: 0)
Raphael club-internet.fr> writes: > > On Tuesday 29 November 2005 22:46, L. Lenders wrote: > > Just for the info: after some digging i found a quick > > hack to get rid of the error: comment line 208 in > > dlls/x11drv/opengl.c: > > > > //TEST_AND_ADD1(ppfd->dwFlags & PFD_STEREO, > > GLX_STEREO); > > No, it's not the good way. > Try my last patch on bug report I think there is still a problem with your patch Raphael. I update the bug report with my observations, but basically it is as follows. glXChooseVisual and glXChooseFBConfig differ in the way they set up attribute lists. glXChooseFBConfig _requires_ all attributes to be followed by a value, even booleans. This implies that TEST_AND_ADD1 should _never_ be used for glXChooseFBConfig and friends. The only place it is being used currently is for GLX_STEREO, which seems to be causing the problems with Doom3. Changing the TEST_AND_ADD1 to a TEST_AND_ADD2 should be enough to correct your patch. Other than that your patch is definitely an improvement. Regards, Aric
RE: Problem with serial port.
Did you check out that flow control is handled correctly from the Olivetti printer. I have had this happen in the past and in every case I found that either I was using the wrong flow control or not taking it into account.
Re: Implement symbolic link object in wineserver.
Tuesday, November 29, 2005, 4:47:47 PM, Robert Shearman wrote:
> Hi Vitaliy,
> This patch looks pretty good, but needs some finishing touches. Are you
> planning to continue the directory work to get objects to start
> supporting it?
Yes I do. It should be a straight forward for events, sections, mutants,
semaphores and timers. But named pipes, mail slots and winstations with
desktops will have to wait a bit. I'm not sure yet how to properly
separate name spaces (you should not be able to create an event in the
named pipe name space. And wise-versa).
> Vitaliy Margolen wrote:
>>+struct syboliclink *create_syboliclink( struct directory *root, const struct
>>unicode_str *name,
>>+unsigned int attr, const struct
>>unicode_str *target )
>>
>>
> Spelling mistake again. Also, should match whatever name is decided for
> the name of the object.
Damn. How in the world did gcc compiled this then? With so many errors?!
I don't know why didn't I see this before. Of course I will change it to
"symlink".
>>+
>>+/* Global initialization */
>>+void init_syboliclinks(void)
>>+{
>>+}
>>+
>>+void close_syboliclinks(void)
>>+{
>>+}
>>
>>
> It would probably be nicer to have all of the namespace initialisation
> done in one place, e.g. directory.c
> That would mean exporting the create_symlink function, but then
> init_symboliclinks and close_symboliclinks would no longer have to be
> exported.
Yup are you right. Done.
>>+if (req->rootdir && !(root = get_directory_obj(
>>current->process, req->rootdir, 0 )))
>>+return;
>>
>>
> Does NT really allow you to open a directory without having any specific
> access rights?
Yup. In the tests I'm opening directory with "directory query" rights
only. And it works when I'm using it as the RootDirectory. Even when
creating new objects in it.
Vitaliy
Re: Question about X11DRV_ChoosePixelFormat glXChooseFBConfig returns NULL (glError: 0)
On Tuesday 29 November 2005 22:46, L. Lenders wrote: > Just for the info: after some digging i found a quick > hack to get rid of the error: comment line 208 in > dlls/x11drv/opengl.c: > > //TEST_AND_ADD1(ppfd->dwFlags & PFD_STEREO, > GLX_STEREO); No, it's not the good way. Try my last patch on bug report Regards, Raphael pgpFtAtddQWi9.pgp Description: PGP signature
Question about X11DRV_ChoosePixelFormat glXChooseFBConfig returns NULL (glError: 0)
Just for the info: after some digging i found a quick hack to get rid of the error: comment line 208 in dlls/x11drv/opengl.c: //TEST_AND_ADD1(ppfd->dwFlags & PFD_STEREO, GLX_STEREO); Somehow setting the PFD_STEREO flag makes doom3 crash and triggers the error mentioned in the subject. After commenting line 208 doom3 starts up just fine. Digging further. :) (any help appreciated) Louis ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Re: Implement symbolic link object in wineserver.
Hi Vitaliy,
This patch looks pretty good, but needs some finishing touches. Are you
planning to continue the directory work to get objects to start
supporting it?
Vitaliy Margolen wrote:
diff --git a/server/object.h b/server/object.h
index 0c2ee1a..1154e0a 100644
--- a/server/object.h
+++ b/server/object.h
@@ -193,6 +193,11 @@ extern obj_handle_t open_object_dir( str
extern void init_directories(void);
extern void close_directories(void);
+/* sybmolic link functions */
+
+extern void init_syboliclinks(void);
+extern void close_syboliclinks(void);
Multiple spelling mistakes.
+
/* global variables */
/* command-line options */
diff --git a/server/symlink.c b/server/symlink.c
new file mode 100644
index 000..5a07df3
--- /dev/null
+++ b/server/symlink.c
@@ -0,0 +1,225 @@
+/*
+ * Server-side symbolic link object management
+ *
+ * Copyright (C) 2005 Vitaliy Margolen
+ *
+ * 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 "config.h"
+#include "wine/port.h"
+
+#include
+#include
+#include
+#include
+#include
+
+#include "ntstatus.h"
+#define WIN32_NO_STATUS
+#include "winternl.h"
+#include "ddk/wdm.h"
+
+#include "handle.h"
+#include "request.h"
+#include "object.h"
+#include "unicode.h"
+
+struct syboliclink
+{
+struct object obj; /* object header */
+struct unicode_str target;/* target of the symlink */
+};
Spelling mistake. In the server the name of the object struct typically
mirrors the name of the file. So in this case it would be "struct symlink"
+
+static void syboliclink_dump( struct object *obj, int verbose );
+static struct object *symlink_lookup_name( struct object *obj, struct
unicode_str *name,
+ unsigned int attr );
+static void syboliclink_destroy( struct object *obj );
Spelling mistakes and lack of consistency with the naming. They should
have the name of the object as a prefix: symlink_dump,
symlink_lookup_name, symlink_destroy.
+struct syboliclink *create_syboliclink( struct directory *root, const struct
unicode_str *name,
+unsigned int attr, const struct
unicode_str *target )
Spelling mistake again. Also, should match whatever name is decided for
the name of the object.
+
+/* Global initialization */
+
+static struct syboliclink *link_dosdev, *link_global1, *link_global2,
*link_local;
+
+void init_syboliclinks(void)
+{
+static const WCHAR dir_globalW[] = {'\\','?','?'};
+static const WCHAR dir_basenamedW[] =
{'\\','B','a','s','e','N','a','m','e','d','O','b','j','e','c','t','s'};
+static const struct unicode_str dir_global_str = {dir_globalW,
sizeof(dir_globalW)};
+static const struct unicode_str dir_basenamed_str = {dir_basenamedW,
sizeof(dir_basenamedW)};
+
+static const WCHAR link_dosdevW[] =
{'\\','D','o','s','D','e','v','i','c','e','s'};
+static const WCHAR link_global1W[] =
{'\\','?','?','\\','G','l','o','b','a','l'};
+static const WCHAR link_global2W[] =
{'\\','B','a','s','e','N','a','m','e','d','O','b','j','e','c','t','s','\\','G','l','o','b','a','l'};
+static const WCHAR link_localW[] =
{'\\','B','a','s','e','N','a','m','e','d','O','b','j','e','c','t','s','\\','L','o','c','a','l'};
+static const struct unicode_str link_dosdev_str = {link_dosdevW,
sizeof(link_dosdevW)};
+static const struct unicode_str link_global1_str = {link_global1W,
sizeof(link_global1W)};
+static const struct unicode_str link_global2_str = {link_global2W,
sizeof(link_global2W)};
+static const struct unicode_str link_local_str = {link_localW,
sizeof(link_localW)};
+
+link_dosdev = create_syboliclink( NULL, &link_dosdev_str, 0,
&dir_global_str );
+link_global1 = create_syboliclink( NULL, &link_global1_str, 0,
&dir_global_str );
+link_global2 = create_syboliclink( NULL, &link_global2_str, 0,
&dir_basenamed_str );
+link_local = create_syboliclink( NULL, &link_local_str, 0,
&dir_basenamed_str );
+}
+
+void close_syboliclinks(void)
+{
+release_object( link_dosdev );
+release_object( link_global1 );
+release_object( link_global2 );
+release_object( link_local );
+}
It would probably be nicer to have all of the namespace initialisation
done in on
Re: msvcrt incompatibility in Origin 6.0 when saving documents
Hello again! Running Origin6.0 with WINEDEBUG="+snoop,+relay" with and without native msvcrt, tailing, cutting and wc-ing and finally diffing the output I found the following: First of all using the native version I get some msvcrt._EH_prolog calls I can't find in the builtin version. all window-procs have such calls: native: ret kernel32.94() retval=0009 ret=7f6c5a5c call window proc 0x6c231b81 (hwnd=0x1003a,msg=wm_settext,wp=,lp=7fadedd4) call msvcrt._eh_prolog(7f6cf147,0001003a,000c,,7fadedd4 "microcal origin - i ret msvcrt._eh_prolog() retval=7db10190 ret=6c231b8b call msvcrt._eh_prolog(6c231b9c,6c23b419,6c231b81,6c231b81,7fadf8ec,6c2c2cfe,0009 ret ntdll.rtlentercriticalsection() retval= ret=7e6563d2 call ntdll.rtlleavecriticalsection(7e69a888) ret=7e656412 ret ntdll.rtlleavecriticalsection() retval= ret=7e656412 \\mnt\\privat\\origin6\\untitled",7f6ee620,0001003a,000c, ...) ret=6c2310b5 ret msvcrt._eh_prolog() retval=7db10190 ret=6c2310b5 call kernel32.tlsgetvalue(0003) ret=6c231018 ret kernel32.tlsgetvalue() retval=7fdd7a88 ret=6c231018 call msvcrt._eh_prolog(6c23138a,,6c231be9,0001003a,7fadeba8,6c231bba,0001003a,000c,,7fadedd4 "microcal origin - i ret msvcrt._eh_prolog() retval=7db10190 ret=6c23112a call kernel32.tlsgetvalue(0003) ret=6c231018 ret kernel32.tlsgetvalue() retval=7fdd7a88 ret=6c231018 call kernel32.tlsgetvalue(0003) ret=6c231018 ret kernel32.tlsgetvalue() retval=7fdd7a88 ret=6c231018 call msvcrt._eh_prolog(6c231bfb,7d9366c0,0001003a,000c,,7fadedd4 "microcal origin - i ret msvcrt._eh_prolog() retval=7db10190 ret=6c231c09 call kernel32.tlsgetvalue(0003) ret=6c231018 builtin: call window proc 0x6c231b81 (hwnd=0x1003a,msg=wm_settext,wp=,lp=7fadedd4) call kernel32.tlsgetvalue(0003) ret=6c231018 This is another example not concerting window procs: native: call kernel32.lstrlena(7fadecc0 "microcal origin") ret=6c2338d7 ret kernel32.lstrlena() retval=000f ret=6c2338d7 call msvcrt._eh_prolog(6c2319c6,000f,7fadedd0,7fd299fc,6c23393c,000f,000f,7fadedd0,6c2338f9,000f,7fadecc0 "microcal origin",7fadedd0,6c2338e0,000f,7fadecc0 "microcal origin",000f, ...) ret=6c231aeb ret msvcrt._eh_prolog() retval=7db101a9 ret=6c231aeb call ntdll.rtlentercriticalsection(6c300088) ret=6c231b03 same as builtin: call kernel32.lstrlena(7fadecc0 "microcal origin") ret=6c2338d7 ret kernel32.lstrlena() retval=000f ret=6c2338d7 call ntdll.rtlentercriticalsection(6c300088) ret=6c231b03 >From mfc there is also such a call: native: call mfc42.6374(000c,,7fadedd4 "microcal origin - i call mfc42.5163(000c,,7fadedd4 "microcal origin - i call msvcrt._eh_prolog(7db101db,000c,,7fadedd4 "microcal origin - i ret msvcrt._eh_prolog() retval=7db101f4 ret=6c231d16 call ntdll.rtlentercriticalsection(6c300220) ret=6c23178e builtin: call mfc42.6374(000c,,7fadedd4 "microcal origin - i call mfc42.5163(000c,,7fadedd4 "microcal origin - i call ntdll.rtlentercriticalsection(6c300220) ret=6c23178e Then there is also a difference when calling ftime(): native: (line 16240) call msvcrt.memcpy(7d945558 "untitled",7fe5e27a "untitled",0008) ret=6c233905 ret msvcrt.memcpy() retval=7d945558 ret=6c233905 ret mfc42.860() retval=7d943dc0 ret=7f81a080 call outl60.labutil_str2date(,0003,) ret=7f81a0fe call msvcrt._ftime() ret=7f74100d call kernel32.getsystemtimeasfiletime(7fadedf0) ret=78026aad call ntdll.ntquerysystemtime(7fadec80) ret=7fd08e30 ret kernel32.getsystemtimeasfiletime() retval=01c5f531 ret=78026aad ret msvcrt._ftime() retval=438cd1d8 ret=7f74100d call msvcrt.localtime() ret=7f74103e call kernel32.getlasterror() ret=78002699 ret kernel32.getlasterror() retval= ret=78002699 call kernel32.tlsgetvalue(0002) ret=780026a7 ret kernel32.tlsgetvalue() retval=7d930088 ret=780026a7 call kernel32.setlasterror() ret=780026b8 ret kernel32.setlasterror() retval= ret=780026b8 ret msvcrt.localtime() retval=7d9306f8 ret=7f74103e builtin: (line 16632) call msvcrt.memcpy(7fe7dff8,7fe637e2,0008) ret=6c233905 ret msvcrt.memcpy() retval=7fe7dff8 ret=6c233905 ret mfc42.860() retval=7fe7aac0 ret=7f81a080 call outl60.labutil_str2date(,0003,) ret=7f81a0fe call msvcrt._ftime(7f75b778) ret=7f74100d call kernel32.gettimezoneinformation(7fadec9c) ret=7e886be4 call ntdll.rtlquerytimezoneinformation(7fadec9c) ret=7fd09bce ret ntdll.rtlquerytimezoneinformation() retval= ret=7fd09bce call ntdll.ntquerysystemtime(7fadebc0) ret=7fd08e30 ret kernel32.gettimezoneinformation() retval= ret=7e886be4 call kernel32.getsystemtimeasfiletime(7faded48) ret=7e886bf3 call ntdll.ntquerysystemtime(7fadebe0) ret=7fd08e30 ret ntdll.ntquerysystemtime() retval= ret=7fd08e30 ret kernel32.getsystemtimeasfiletime() retval=01c5f530 ret=7e886b
Re: PATCH/RFC: imagelist rewrite to use N x M grid
Tuesday, November 29, 2005, 1:37:01 PM, Marcus Meissner wrote: > On Tue, Nov 29, 2005 at 01:24:47PM -0700, Vitaliy Margolen wrote: >> Tuesday, November 29, 2005, 12:58:55 PM, Marcus Meissner wrote: >> > On Mon, Nov 28, 2005 at 09:55:57PM -0600, Dustin Navea wrote: >> >> H. I havent tested due to sys overhaul, but it seems that this >> >> should work. Just out of curiosity, what was the reason for picking 4 >> >> as the magic number? >> >> > Randomness. Any number could be used. >> I think native uses 4. As I remember, Delphi understands only 4xN. >> So when you edit an imagelist in IDE and save it, Delphi could not use >> produced output and was crashing/displaying corrupted images. > So our current implementation has problems? Correct. It work as long as you don't try to save image list to stream. > Is this the Read/Write to/from IStream interface to imagelists? Yes. Delphi stores that information in the raw form during the design time. So when application start it reads whole image list from resources. In other words. What Wine saves to stream is not binary compatible with windows. To make it compatible it has to be 4xN bitmap. Vitaliy.
Re: PATCH/RFC: imagelist rewrite to use N x M grid
On Tue, Nov 29, 2005 at 01:24:47PM -0700, Vitaliy Margolen wrote: > Tuesday, November 29, 2005, 12:58:55 PM, Marcus Meissner wrote: > > On Mon, Nov 28, 2005 at 09:55:57PM -0600, Dustin Navea wrote: > >> H. I havent tested due to sys overhaul, but it seems that this > >> should work. Just out of curiosity, what was the reason for picking 4 > >> as the magic number? > > > Randomness. Any number could be used. > I think native uses 4. As I remember, Delphi understands only 4xN. > So when you edit an imagelist in IDE and save it, Delphi could not use > produced output and was crashing/displaying corrupted images. So our current implementation has problems? Is this the Read/Write to/from IStream interface to imagelists? > > However I got another suggestion to just store all the images in > > an array (of HBITMAP or similar). > > > > Does anything speak against doing this instead of having this > > large bitmap and cutting out the images? > > The problem is that you can't read it as-is from the stream. Also you > will have to put it back together into a single bitmap to save it. Also > some ops require operation on the whole image list. And last but not > least, it will be much slower, as you will have to create/delete DCs each > time you need to use imagelist. Ah ok. Ciao, Marcus
Re: PATCH/RFC: imagelist rewrite to use N x M grid
Tuesday, November 29, 2005, 12:58:55 PM, Marcus Meissner wrote: > On Mon, Nov 28, 2005 at 09:55:57PM -0600, Dustin Navea wrote: >> H. I havent tested due to sys overhaul, but it seems that this >> should work. Just out of curiosity, what was the reason for picking 4 >> as the magic number? > Randomness. Any number could be used. I think native uses 4. As I remember, Delphi understands only 4xN. So when you edit an imagelist in IDE and save it, Delphi could not use produced output and was crashing/displaying corrupted images. > However I got another suggestion to just store all the images in > an array (of HBITMAP or similar). > > Does anything speak against doing this instead of having this > large bitmap and cutting out the images? The problem is that you can't read it as-is from the stream. Also you will have to put it back together into a single bitmap to save it. Also some ops require operation on the whole image list. And last but not least, it will be much slower, as you will have to create/delete DCs each time you need to use imagelist. Vitaliy
Re: PATCH/RFC: imagelist rewrite to use N x M grid
On Mon, Nov 28, 2005 at 09:55:57PM -0600, Dustin Navea wrote: > H. I havent tested due to sys overhaul, but it seems that this > should work. Just out of curiosity, what was the reason for picking 4 > as the magic number? Randomness. Any number could be used. However I got another suggestion to just store all the images in an array (of HBITMAP or similar). Does anything speak against doing this instead of having this large bitmap and cutting out the images? Ciao, Marcus
Re: WSACleanup fix.
Rein Klazes wrote:
On Tue, 29 Nov 2005 10:33:49 -0600, you wrote:
if (num_startup)
+{
+num_startup--;
return 0;
+}
Yes, that is more correct. Re-reading the MSDN this is what should be
happening.
Changelog:
dlls/winsock: socket.c
dlls/winsock/tests : sock.c
(With input from Robert Shearman) Decrement the reference counter in
WSACleanUp with regression test.
Alexandre already committed a corrected version of your patch.
--
Rob Shearman
Re: WSACleanup fix.
Tuesday, November 29, 2005, 12:10:52 PM, Rein Klazes wrote:
> On Tue, 29 Nov 2005 10:33:49 -0600, you wrote:
>> if (num_startup)
>>+{
>>+num_startup--;
>> return 0;
>>+}
> Yes, that is more correct. Re-reading the MSDN this is what should be
> happening.
> Changelog:
> dlls/winsock : socket.c
> dlls/winsock/tests: sock.c
> (With input from Robert Shearman) Decrement the reference counter in
> WSACleanUp with regression test.
> Rein.
I think you a little too late. Check the CVS log.
Vitaliy
Re: WSACleanup fix.
On Tue, 29 Nov 2005 10:33:49 -0600, you wrote:
> if (num_startup)
>+{
>+num_startup--;
> return 0;
>+}
Yes, that is more correct. Re-reading the MSDN this is what should be
happening.
Changelog:
dlls/winsock: socket.c
dlls/winsock/tests : sock.c
(With input from Robert Shearman) Decrement the reference counter in
WSACleanUp with regression test.
Rein.
--- wine/dlls/winsock/socket.c 2005-11-24 17:00:02.0 +0100
+++ mywine/dlls/winsock/socket.c2005-11-29 20:01:53.0 +0100
@@ -830,8 +830,10 @@ int WINAPI WSAStartup(WORD wVersionReque
*/
INT WINAPI WSACleanup(void)
{
-if (num_startup)
+if (num_startup) {
+num_startup -= 1;
return 0;
+}
SetLastError(WSANOTINITIALISED);
return SOCKET_ERROR;
}
--- wine/dlls/winsock/tests/sock.c 2005-11-14 20:31:23.0 +0100
+++ mywine/dlls/winsock/tests/sock.c2005-11-29 14:33:08.0 +0100
@@ -709,8 +709,15 @@ static void Init (void)
static void Exit (void)
{
+INT ret, err;
TlsFree ( tls );
-ok ( WSACleanup() == 0, "WSACleanup failed\n" );
+ret = WSACleanup();
+err = WSAGetLastError();
+ok ( ret == 0, "WSACleanup failed ret = %d GetLastError is %d\n", ret,
err);
+ret = WSACleanup();
+err = WSAGetLastError();
+ok ( ret == SOCKET_ERROR && err == WSANOTINITIALISED,
+"WSACleanup returned %d GetLastError is %d\n", ret, err);
}
static void StartServer (LPTHREAD_START_ROUTINE routine,
Re: Compiling wine on Ubuntu amd64
keep wine-devel list cc'ed. James Trotter schrieb: > On 11/29/05, Peter Beutner <[EMAIL PROTECTED]> wrote: >> >>I think we should rather get rid of including >>/usr/include/X11/Intrinsic.h. >>The code in x11drv which include this header doesn't even link against >>libXt. >>(and afaik no other part of wine does it) > > So, you'd say it's safe to remove any includes of X11/Intrinsic.h in the > wine source? If so, I'd be willing to do this as soon as I can. Just do an 'cvs update' ;). Alexandre Julliard already fixed it today.
Re: msvcrt incompatibility in Origin 6.0 when saving documents
Hello, Olaf Leidinger wrote: I'm testing Origin 6.0 using wine-0.9.1 and everything is really fine except saving documents. I'm getting a crash here. Just before that crash there is a dialog telling me: "File not saved. Please ensure that the disk isn't full" (roughly translated). Using a native version of msvcrt everything works fine. So I suppose that the problem lies in the builtin msvcrt ;-) Running origin60.exe using +relay, I also get the message dialog, but the app doesn't crash. (Timing problem?) Perhaps anybody could tell me where to start looking for the problem. Going trough the +relay-logs I can't find anything suspect. But I'm not very familliar with the win32 api ;-( Just for information: Using CrossOver Office (at least since their nightlies of approx. 2005-06-28) it works. There is something strange: If I install using CrossOverOffice and point Wine 0.9.1 to CXO's directory (ln -s ../.cxoffice/default/* ~/.wine) then I can save files in Origin 6 under Wine 0.9.1. That means that either the installation needs a feature CXO provides or some files on the harddisc have the needed feature (I'm currently not sure whether DCOM needs to be installed, I think it is not.) Tobias PS: See also bug 3115 ( http://bugs.winehq.org/show_bug.cgi?id=3115 ), which does not provide more infomation.
Re: Please HELP, info required about 'DIB_Status_GdiMod' and 'DIB_Status_AppMod'
Marinescu-Ghetau Iulian wrote: Hello, Could anyone give me some more info on X11DRV_CoerceDIBSection function and the logic behind using 'DIB_Status_GdiMod' and 'DIB_Status_AppMod' stats? I am trying to repair a bug (3902) that has to do with application waiting exccessivly on some locks and i am kind of lost ;( Any help would be greatly appreciated! That code is designed to keep DIBs sync'ed between applications and the X server. When the application does a Win32 GDI call then the state of the DIB gets set to DIB_Status_GdiMod and the memory that backs the DIB is set to no-access so that a page fault occurs if the application tries to read it. A handler detects this and downloads the DIB from the X server and sets the state to DIB_Status_None. In this state the DIB memory is set to read-only, so that a page fault occurs if the application tries to write it. The same handler also detects this and consequentially sets the DIB state to DIB_Status_AppMod and allows full access to the DIB memory. If this doesn't answer help with your bug then you'll have to be more specific. -- Rob Shearman
Re: RESEND: Page Fault With Freetype calls fixed
Rein Klazes <[EMAIL PROTECTED]> writes: > Not included in the new release, no comments. Is there a problem with > this one ? I think it would be cleaner to have WineEngGetFontData do the right thing directly, instead of calling it twice. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Question about current Shell Folder registry settings...
Hi Markus, On Tuesday 29 November 2005 14:47, Markus Gömmel wrote: > Can anybody tell me why "Desktop" is set to Z: instead of set to > "c:\windows\profiles\mgoemmel\Desktop"? The code that figures the paths for the 'Personal' and 'Desktop' shellfolders is in dlls/shell32/shellpath.c's _SHGetDefaultValue, starting at line 1261. It queries the $HOME environment variable, which holds the path that refers to the folder that conceptually represents what 'My Documents' is on Windows. The 'Desktop' folder in your $HOME is what conceptually matches the Windows Desktop folder (At least on KDE. And though I can't find it just yet, I guess that's the freedesktop.org standard directory for the desktop). > And as a second question: would it be ok to add "My Music", "My Pictures" > and "My Video" to this registry key? I would do this if anybody would agree > that it's ok, and would send the necessary patches. Some if my programs > blames me about these three missing values. If yes, where should it point > to? z:\home\mgoemmel\My Music? Or would it be not much better to also point > "Personal" to "c:\windows\profiles\mgoemmel\My Documents" too? You probably should add CSIDL_MY[MUSIC|VIDEO|PICTURES] to the 'folders' array in shellpath.c's _SHRegisterUserShellFolders function. This would generate the appropriate registry entries. With the current implementation those would all point to the user's home directory. In _SHGetDefaultValue, you could check for 'My Music', 'My Videos' and 'My Pictures' folders in $HOME and, if they are present, map to those instead. Bye, -- Michael Jung [EMAIL PROTECTED]
Re: WSACleanup fix.
Rein Klazes wrote:
--- wine/dlls/winsock/socket.c 2005-11-24 17:00:02.0 +0100
+++ mywine/dlls/winsock/socket.c2005-11-29 14:58:24.0 +0100
@@ -830,8 +830,10 @@ int WINAPI WSAStartup(WORD wVersionReque
*/
INT WINAPI WSACleanup(void)
{
-if (num_startup)
+if (num_startup) {
+num_startup = 0;
return 0;
+}
SetLastError(WSANOTINITIALISED);
return SOCKET_ERROR;
}
Hi,
I don't think the patch is quite correct. Attached is a patch that has
been sitting in my tree for a while.
--
Rob Shearman
? dlls/winsock/winsock.spec.c
? dlls/winsock/ws2_32.dll.dbg.c
? dlls/winsock/ws2_32.dll.so.debug
Index: dlls/winsock/socket.c
===
RCS file: /home/wine/wine/dlls/winsock/socket.c,v
retrieving revision 1.199
diff -u -p -r1.199 socket.c
--- dlls/winsock/socket.c 28 Nov 2005 20:10:42 - 1.199
+++ dlls/winsock/socket.c 29 Nov 2005 16:31:39 -
@@ -832,7 +832,10 @@ int WINAPI WSAStartup(WORD wVersionReque
INT WINAPI WSACleanup(void)
{
if (num_startup)
+{
+num_startup--;
return 0;
+}
SetLastError(WSANOTINITIALISED);
return SOCKET_ERROR;
}
Re; Question about current Shell Folder registry settings...
Hi Markus, > Desktopz:\home\mgoemmel\Desktop (snip) > Can anybody tell me why "Desktop" is set to Z: instead of set > to "c:\windows\profiles\mgoemmel\Desktop"? Because this (z:\home\mgoemmel\Desktop) is the location of your Linux desktop. If you save stuff to "Desktop," you expect it to appear there, yes? Perhaps this shouldn't be done inside shell32 (where it currently is), but in winecfg instead. The trouble of course is that winecfg isn't run during installation. There was a patch that ran winecfg in an install mode from wineprefixcreate, had it gone in this would be possible. > And as a second question: would it be ok to add "My Music", > "My Pictures" and "My Video" to this registry key? I would do > this if anybody would agree that it's ok, and would send the > necessary patches. Some if my programs blames me about these > three missing values. If an app depends on them, then yes, by all means do. > If yes, where should it point to? z:\home\mgoemmel\My Music? > Or would it be not much better to also point "Personal" to > "c:\windows\profiles\mgoemmel\My Documents" too? Several questions in one here! Well, since Linux doesn't really have a "My Music" folder, I think it makes sense just to point it to the same place as "Personal," wherever that is. That, in turn, defaults to ~, since that is the closest thing to a "My Documents" directory in Linux. Incidentally, if you don't like the defaults, you can always change them. Just be sure to change them in "User Shell Folders" rather than "Shell Folders," the latter is deprecated and is treated as read-only (by both MS and Wine.) --Juan __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Does the Windows version of Mozilla need to be installed to use the Mozilla ActiveX plugin?
Does the Windows version of Mozilla need to be in place for the Mozilla Active X control to work, or is there a way to point the control at my Linux install of Mozilla?
Re: msvcrt incompatibility in Origin 6.0 when saving documents
Hello, Olaf Leidinger wrote: I'm testing Origin 6.0 using wine-0.9.1 and everything is really fine except saving documents. I'm getting a crash here. Just before that crash there is a dialog telling me: "File not saved. Please ensure that the disk isn't full" (roughly translated). Using a native version of msvcrt everything works fine. So I suppose that the problem lies in the builtin msvcrt ;-) Running origin60.exe using +relay, I also get the message dialog, but the app doesn't crash. (Timing problem?) Perhaps anybody could tell me where to start looking for the problem. Going trough the +relay-logs I can't find anything suspect. But I'm not very familliar with the win32 api ;-( Just for information: Using CrossOver Office (at least since their nightlies of approx. 2005-06-28) it works. There is something strange: If I install using CrossOverOffice and point Wine 0.9.1 that installation (ln -s ../.cxoffice/default/* ~/.wine) then I can save using Wine 0.9.1. That means that either the installation needs a feature CXO provides or some files on the harddisc have the needed feature (I'm currently not sure whether DCOM needs to be installed, I think it is not.) Tobias
Re: Latest CVS download opensolaris, AMD 64, build errors
On Mon, 28 Nov 2005 01:56 pm, Mike McCormack wrote: > David Clack wrote: > > I'm on OpenSolaris B27, on an AMD 64 system, I'm getting these errors > > from the build. > > I guess not alot of people use that configuration ... > Did you apply the patches from http://www.blastwave.org/wine
Question about current Shell Folder registry settings...
Hello, HKEY_CURRENT_USER/Software/Microsoft/Windows/CurrentVersion/ShellFolders has the following settings on a freshly installed system after first calling wine: AppDatac:\windows\profiles\mgoemmel\Application Data Cookiesc:\windows\profiles\mgoemmel\Cookies Desktopz:\home\mgoemmel\Desktop Favoritesc:\windows\profiles\mgoemmel\Favorites ... Personalz:\home\mgoemmel ... StartMenuc:\windows\profiles\mgoemmel\Start Menu Can anybody tell me why "Desktop" is set to Z: instead of set to "c:\windows\profiles\mgoemmel\Desktop"? And as a second question: would it be ok to add "My Music", "My Pictures" and "My Video" to this registry key? I would do this if anybody would agree that it's ok, and would send the necessary patches. Some if my programs blames me about these three missing values. If yes, where should it point to? z:\home\mgoemmel\My Music? Or would it be not much better to also point "Personal" to "c:\windows\profiles\mgoemmel\My Documents" too? Thanks for any answers and/or discussions... Markus Goemmel [EMAIL PROTECTED]
Re: Implement directory object in wineserver.
Hi, On 11/28/05, Vitaliy Margolen <[EMAIL PROTECTED]> wrote: > Change tests accordingly. This reminded me, I meant to send you a note when this test was first added. The test needs some loving for Windows Server 2003. om.c:190: Test failed: Failed create returned valid handle! (80905558) om.c:202: Test failed: NtCreateMutant should have failed with STATUS_OBJECT_TYPE _MISMATCH got(c03a) om.c:215: Test failed: NtCreateMutant should have succeeded with STATUS_OBJECT_N AME_EXISTS got() om.c:228: Test failed: NtCreateEvent should have succeeded with STATUS_OBJECT_NA ME_EXISTS got() om.c:241: Test failed: NtCreateSemaphore should have succeeded with STATUS_OBJEC T_NAME_EXISTS got() om.c:254: Test failed: NtCreateTimer should have succeeded with STATUS_OBJECT_NA ME_EXISTS got() om.c:269: Test failed: NtCreateSection should have succeeded with STATUS_OBJECT_ NAME_EXISTS got() om: 105 tests executed, 0 marked as todo, 7 failures. -- Steven Edwards - ReactOS and Wine developer "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: msvcrt incompatibility in Origin 6.0 when saving documents
On Tue, 29 Nov 2005 02:43:39 +0100, you wrote: >... some _mbsinc calls > >... some putc calls > >And finally ... > >0009:Call msvcrt.fclose(7fe8fa90) ret=7f81ecf0 [snip] >0009:Ret msvcrt.fclose() retval= ret=7f81ecf0 >0009:Call kernel32.OpenFile(7fe60252 >"i:\\mnt\\privat\\Origin6\\UNTITLED.opj",7fadf040,0200) ret=7f81ed08 This open file is really doing a delete (0x200 is OF_DELETE ). I guess that is part of the error exit and that the cause is in those putc and _mbsinc calls. Rein.
reports are not well shown
Hi im runing my acces97 application. The problem is when im going to watch a report, letters are not well shown. I have installed all the fonts (arial...) and it keeps on. The text seems to be justified. I have traced the program trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\wineps.drv" : builtin trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system\\wineps.drv" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\wineps.drv" : builtin trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system\\wineps.drv" : builtin trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\wineps.drv" : builtin fixme:font:load_VDMX Failed to retrieve vTable fixme:font:load_VDMX Failed to retrieve vTable fixme:font:load_VDMX Failed to retrieve vTable trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system\\wineps.drv" : builtin maybe is something with printer ( im using the cups printer). But the funny thing is that i can see some other kinds of report.
Re: REG_EXPAND_SZ not parsed correctly
On Tue, 29 Nov 2005, Cihan Altinay wrote: Hi, I have a .reg file exported from Windows that contains the following entry: "HelpLink"=hex(2):68,00,74,00,74,00,70,00,3a,00,2f,00,2f,00,77,00,77,00,77,00,\ 2e,00,6d,00,69,00,63,00,72,00,6f,00,73,00,6f,00,66,00,74,00,2e,00,63,00,6f,\ 00,6d,00,2f,00,73,00,75,00,70,00,70,00,6f,00,72,00,74,00,00,00 I believe one of the problems with Wine's regedit is that it does not deal correctly with Unicode .reg files. The symptoms you describe seem to confirm this. So it's probably regedit that needs fixing. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.
Please HELP, info required about 'DIB_Status_GdiMod' and 'DIB_Status_AppMod'
Hello, Could anyone give me some more info on X11DRV_CoerceDIBSection function and the logic behind using 'DIB_Status_GdiMod' and 'DIB_Status_AppMod' stats? I am trying to repair a bug (3902) that has to do with application waiting exccessivly on some locks and i am kind of lost ;( Any help would be greatly appreciated! Iulian
Re: Problem with serial port
> "Félix" == Félix Ortega <[EMAIL PROTECTED]> writes: Félix> I'm starting to thing that there is a problem with the way the Félix> serial port is initialized, but I don't have any proof of that. Didn't Cihan already found some mismatches in initialization. Perhaps there is more mismatch lingering around. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Problem with serial port
Quoting Uwe Bonnes <[EMAIL PROTECTED]>: "Félix" == Félix Ortega <[EMAIL PROTECTED]> writes: Félix> Sorry, with my desesperation I forgot to tell you the version of Félix> wine I'm running is the 0.9.2 version. I have tried 0.9.0 and Félix> 0.9.1, with the same result. The strange thing is the driver does Félix> not use the WaitCommEvent call, tha I think is work in progress Félix> now. No, most WaitCommEvent functionality is there. Maybe heavy use of threads and some special case still cause trouble. Ok, I think the problem with the other driver is essentially the same, but the second driver uses WaitCommEvent (with events) and the first driver uses timeouts (polling). But the problem I think is the data never gets written to the port (something related to flow control?) Félix> I have another driver for a similar printer that does use Félix> this call, and doesn't work neither. I'm studying the windows Félix> source code of this second driver (I have access to it) to make a Félix> linux program that at least initialize the printer. I will keep Félix> you informed on this second project. Look at the test directories and try to create tests mimicing your error. I will try to do that, I haven't looked the test dir too much. Félix> For the olivetti printer, I Félix> don't know what is the problem, and I don't know where to look Félix> for :(. Perpaps some serial spy would be of help. Capture the communication of the windows program with the device, do the same under wine and compare. I have done that, with portmon on the windows side and with some patches that you (I think) sent to the list, so the write and read operations log the contents. The data is the same, and the sequence also, but on wine the data never gets to the printer, It stalls on the buffer and after a timeout the program clears the output buffer and starts again. At first I thought that the problem was related with the asynchronous I/O (somehow the timeout fires before the data gets written), so I disabled the asynchronous write for ports, as said on a thread I found on google. The diff was something like changing the line if (flags & (FD_FLAG_OVERLAPPED|FD_FLAG_TIMEOUT)) with if (flags & (FD_FLAG_OVERLAPPED)) at function NtWriteFile on ntdll/file.c file, so the write never gets its own thread unles specified. But the problem remains the same, but the timeout never get's fired and the program hangs trying to write on the serial port. I'm starting to thing that there is a problem with the way the serial port is initialized, but I don't have any proof of that. Thanks! However I don't have a suggestion for a serial caputure program for you :-( -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 -- This message was sent using IMP, the Internet Messaging Program.
Re: Problem with serial port
Uwe Bonnes wrote: Perpaps some serial spy would be of help. Capture the communication of the windows program with the device, do the same under wine and compare. However I don't have a suggestion for a serial caputure program for you :-( How about the freeware Portmon from sysinternals: http://www.sysinternals.com/Utilities/Portmon.html It helped me a lot... Cheers, Cihan
Re: Problem with serial port
> "Félix" == Félix Ortega <[EMAIL PROTECTED]> writes: Félix> Sorry, with my desesperation I forgot to tell you the version of Félix> wine I'm running is the 0.9.2 version. I have tried 0.9.0 and Félix> 0.9.1, with the same result. The strange thing is the driver does Félix> not use the WaitCommEvent call, tha I think is work in progress Félix> now. No, most WaitCommEvent functionality is there. Maybe heavy use of threads and some special case still cause trouble. Félix> I have another driver for a similar printer that does use Félix> this call, and doesn't work neither. I'm studying the windows Félix> source code of this second driver (I have access to it) to make a Félix> linux program that at least initialize the printer. I will keep Félix> you informed on this second project. Look at the test directories and try to create tests mimicing your error. Félix> For the olivetti printer, I Félix> don't know what is the problem, and I don't know where to look Félix> for :(. Perpaps some serial spy would be of help. Capture the communication of the windows program with the device, do the same under wine and compare. However I don't have a suggestion for a serial caputure program for you :-( -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Problem with serial port
Sorry, with my desesperation I forgot to tell you the version of wine I'm running is the 0.9.2 version. I have tried 0.9.0 and 0.9.1, with the same result. The strange thing is the driver does not use the WaitCommEvent call, tha I think is work in progress now. I have another driver for a similar printer that does use this call, and doesn't work neither. I'm studying the windows source code of this second driver (I have access to it) to make a linux program that at least initialize the printer. I will keep you informed on this second project. For the olivetti printer, I don't know what is the problem, and I don't know where to look for :(. Thanks to all. Quoting Uwe Bonnes <[EMAIL PROTECTED]>: "Félix" == Félix Ortega <[EMAIL PROTECTED]> writes: Félix> Quoting Cihan Altinay <[EMAIL PROTECTED]>: >> Quoting Félix Ortega <[EMAIL PROTECTED]>: >> >>> I'm trying to make work a driver for a financial printer (Olivetti >>> Pr20) on wine. I'm having problems with the serial port, it seems >>> that no data is written to the device. I have tried everything I >>> have thinked, searched on >> Please try the attached patch with the latest cvs. It is a >> workaround for a symptom where data is flushed away in wine but not >> in Windows. It would be interesting to know if that works for you as >> well. >> Félix, just to make things sure, are you running a recent wine? -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 -- This message was sent using IMP, the Internet Messaging Program.
Re: Problem with serial port
> "Félix" == Félix Ortega <[EMAIL PROTECTED]> writes: Félix> Quoting Cihan Altinay <[EMAIL PROTECTED]>: >> Quoting Félix Ortega <[EMAIL PROTECTED]>: >> >>> I'm trying to make work a driver for a financial printer (Olivetti >>> Pr20) on wine. I'm having problems with the serial port, it seems >>> that no data is written to the device. I have tried everything I >>> have thinked, searched on >> Please try the attached patch with the latest cvs. It is a >> workaround for a symptom where data is flushed away in wine but not >> in Windows. It would be interesting to know if that works for you as >> well. >> Félix, just to make things sure, are you running a recent wine? -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: msvcrt incompatibility in Origin 6.0 when saving documents
> "Olaf" == Olaf Leidinger <[EMAIL PROTECTED]> writes: Olaf> Hello again! >> Try running the application with the debugger and builtin >> msvcrt. Perhaps you get a backtrace of the crash. Otherwise try in >> the relay trace (builtin msvcrt, showing the messagebox but not the >> crash) to find where the messagebox is called. You can seach for the >> message text. Now work up the log and try to find why the program >> decides to emit the messagebox. >> Olaf> Well, the debugger doesn't tell me anything, as the backtrace is Olaf> only one line long and it doesn't contain any information. I Olaf> digged a bit deeper in the relay-log. After the save-file dialog I Olaf> found this: If it is a heap overwrote, try running with WINEDEBUG=+heap. This will check the heap with each heap operation and will immediately tell you when something hag gone wrong (but not where). Otherwise perhaps try running with WINEDEBUG=+snoop,+relay and compare each msvcrt call. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Problem with serial port
Quoting Cihan Altinay <[EMAIL PROTECTED]>: Quoting Félix Ortega <[EMAIL PROTECTED]>: I'm trying to make work a driver for a financial printer (Olivetti Pr20) on wine. I'm having problems with the serial port, it seems that no data is written to the device. I have tried everything I have thinked, searched on Please try the attached patch with the latest cvs. It is a workaround for a symptom where data is flushed away in wine but not in Windows. It would be interesting to know if that works for you as well. Cheers, Cihan It does not work :( The test program freezes trying to flush the serial port (at function PurgeComm). Just before that the trace says that the cbOutQue has 6 elements (at function ClearCommError). I think the program writes on the serial port, but for any reason the writing operation doesn't succeed and the writing operation stalls trying to do the tcdrain part. The program does not stops with tcflush because tcflush discards the buffers. Perhaps is something related to the line discipline of the port, somehow the port doesn't accept input. I keep investigating, many thanks! This message was sent using IMP, the Internet Messaging Program.
Re: Compiling wine on Ubuntu amd64
James Trotter schrieb: > I also encountered another quirk, and needed to install libxt-dev, because > the header file /usr/include/X11/Intrinsic.h was missing. The Wine package > should probably depend on libxt-dev. I think we should rather get rid of including /usr/include/X11/Intrinsic.h. The code in x11drv which include this header doesn't even link against libXt. (and afaik no other part of wine does it) > Then, the compilation failed with: > > ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./gdi32.spec > dispdib.spec.o gdi.exe.spec.o wing.spec.o bidi16.o dispdib.o env.o gdi16.o > wing.o bidi.o bitblt.o bitmap.o brush.o clipping.o dc.o dib.o driver.o > enhmetafile.o enhmfdrv/bitblt.o enhmfdrv/dc.o enhmfdrv/graphics.o > enhmfdrv/init.o enhmfdrv/mapping.o enhmfdrv/objects.o font.o > freetype.ogdi_main.o > gdiobj.o icm.o mapping.o metafile.o mfdrv/bitblt.o mfdrv/dc.o > mfdrv/graphics.o mfdrv/init.o mfdrv/mapping.o mfdrv/objects.o mfdrv/text.o > painting.o palette.o path.o pen.o printdrv.o region.o version.res -o > gdi32.dll.so -L../../dlls -L../../dlls/advapi32 -L../../dlls/kernel32 > -L../../dlls/ntdll -ladvapi32 -lkernel32 -lntdll -L../../libs/wine -lwine > -L../../libs/unicode -lwine_unicode /usr/lib/libsicuuc.a > /usr/lib/libsicudata.a -lstdc++ -lgcc_s -L../../libs/port -lwine_port > ld: Relocatable linking with relocations from format elf64-x86-64 > (/usr/lib/libsicuuc.a(ubidi.ao)) to format elf32-i386 (gdi32.Q3Qz7R.o) is > not supported winebuild: ld -m elf_i386 -r failed with status 256 As the error message says: linking a 32bit object against a 64bit library(libsicuuc.a) doesn't work. I don't know where the /usr/lib/libsicuuc.a library comes from( I don't have it on my system), but you need a ia32 version of the package the library belongs to.
