I am about to have a go at tidying up a little problem with the statusbar
and our application and I want to check as to what we really know and what
we are currently guessing.
Our application has a sunken owner-drawn part in the status bar, in which we
draw multiple icons. Under WINE the part is not sunken (and the icons are
poorly rendered - a separate issue) but the background colour is OK.
I see that currently the code for statusbar is:
For all parts
If owner drawn then let the owner …
[View More]draw it
else
fill the background
if ownerdrawn then let the owner draw it (legacy
code)
else
draw the border
if there is an icon then draw it
draw the text.
fi
fi
end for
Can anyone justify this order as opposed to e.g. draw the background, draw
the border, then if owner drawn let the owner draw the rest, otherwise draw
the icon and text?
It seems to me that the latter is more consistant with what I see but I
don't want to break a load of stuff.
Bill
[View Less]
--- ziolas <ziolas11(a)poczta.onet.pl> wrote:
> Well I've been trying to get UT and DeusEx to work
> under winex 2.0 (yeah I
> know about the linux binaries for UT). It both work
> great under software
> rendering but in HW they suck. In D3D the game loads
> up, then complains about
> vertex buffer and shuts down. In opengl it doesn't
> display any 3d graphics
> (ex. in deus ex I can see the menu, but not the 3d
> logo behind it), and the
> console is …
[View More]flooded with "beginpaint not called on
> WM_PAINT" messages. This is
> probably a bug which should be fixed. Good luck to
> the winex devel's!
>
this message is probably better suited to the winex
forums, but let me take a look at it and see whats up,
be right back
__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
[View Less]
It seems mingw tries to include stdlib.h after windef.h in the build
process and that was the result of the warnings/error.
By making this change I don't have to change any of the other headers
That depend on MAX_PATH (winnls,wingdi) by adding stdlib.h in them.
I don't know if its right by the wine project standards but now I can
compile 90% of the wine dll sources without warrnings/errors from
stupid MAX_PATH. If someone has a better way please cvs diff -u me =)
Thanks
Steven
Changelog:…
[View More] Fix the MAX_PATH mess under Mingw. (for real this time)
cvs diff -u windef.h
Index: windef.h
===================================================================
RCS file: /home/wine/wine/include/windef.h,v
retrieving revision 1.62
diff -u -r1.62 windef.h
--- windef.h 10 Mar 2002 00:02:34 -0000 1.62
+++ windef.h 30 Apr 2002 21:41:42 -0000
@@ -149,6 +149,10 @@
#endif
#endif /* NOMINMAX */
+#ifdef __MINGW__
+#include <stdlib.h>
+#else
+
#ifndef _MAX_PATH
/* FIXME: These are supposed to be in stdlib.h only */
#define _MAX_DRIVE 3
@@ -156,9 +160,13 @@
#define _MAX_DIR _MAX_FNAME
#define _MAX_EXT _MAX_FNAME
#define _MAX_PATH 260
-#endif
+#endif /* _MAX_PATH */
+
+#ifndef MAX_PATH
#define MAX_PATH _MAX_PATH
+#endif /* MAX_PATH */
+#endif /* __MINGW__ */
#define HFILE_ERROR ((HFILE)-1)
[View Less]
Hi all,
I've got an interesting problem on my hands - I need to invoke some
winelib compiled win32 code from java (though jni) on a sparc-solaris
box.
Unfortunately I'm running into problems with the libthread.so library.
If I create the JVM (which involves loading libthread.so) before wine,
I get a segfault in the wine process_init function (during a call to
getcwd that works its way down into libthread). If I instead
initialize wine first, and then dlopen libthread.so and try to create
the …
[View More]JVM, I get a segfault in the JVM code, in a function who's name
includes the word thread (if that actually means anything).
I've seen a few indications on the mailing list and in the docs that
wine is not compatible with pthreads, but I haven't found a concrete
discussion that gets into a lot of details - if anyone knows of a
document somewhere that talks about this, I'd love to see it.
I notice that there is a pthread.c file in scheduler, that seems to
implement part of the pthreads api in terms of wine threads for glibc.
Does anyone know if it would be possible to get something similar
working on solaris?
Does anyone have any other suggestions on how I might be able to make
this work?
Thanks!
Warren
[View Less]
Question - I modified WCMD to support the 'TITLE' command which passed it
through to SetConsoleTitle(A), and a simple program which subsequently calls
GetConsoleTitle shows that the new value is in effect, but I dont see any
window title for the WCMD shell.
Is this a limitation of the console handling? (I tried with Managed='Y' and
with no Managed line in my config file and the result was the same)
Should I submit the patch to support the title command even though it will
not be displayed …
[View More]currently? Its simple enough to do.
Regards,
Jason
[View Less]
With yesterday's cvs, opening a document causes it to crash with this output
on the console:
fixme:listview:LISTVIEW_UnsupportedStyles LVS_SHAREIMAGELISTS
fixme:listview:LISTVIEW_SetItemCount flags LVSICF_NOINVALIDATEALL
LVSICF_NOSCROLL not implemented
fixme:file:FindFirstChangeNotificationA this is not supported yet
(non-trivial).
fixme:mpr:WNetGetUniversalNameW (L"Z:\\DOS\\My Documents\\Lkdjs ldkjsdlkj
sdlkj s.doc", 0x00000001, 0x40552218, 0x4055263c): stub
fixme:mpr:…
[View More]WNetGetUniversalNameW (L"Z:\\DOS\\My Documents", 0x00000001,
0x40553d68, 0x4055418c): stub
fixme:mpr:WNetGetUniversalNameW (L"Z:\\DOS\\My Documents\\Lkdjs ldkjsdlkj
sdlkj s.doc", 0x00000001, 0x4055435c, 0x40554780): stub
fixme:mpr:WNetGetUniversalNameW (L"Z:\\DOS\\My Documents\\Lkdjs ldkjsdlkj
sdlkj s.doc", 0x00000001, 0x405532b0, 0x405536d4): stub
X Error of failed request: BadValue (integer parameter out of range for
operation)
Major opcode of failed request: 1 (X_CreateWindow)
Value in failed request: 0x0
Serial number of failed request: 30392
Current serial number in output stream: 30395
--
michael cardenas
lead windows compatibility engineer
lindows.com
"Be the change you want to see in the world"
-Mahatma Gandhi
[View Less]
Hi, I havent had any replies to the attached issue I was debugging - Can
anyone assist, or should I just submit the patch. I know the patch works but
I feel it is just masking a compatibility problem between two of the wine
internal routines.
Jason
-----Original Message-----
Hello,
I am still investigating this argv/argc issue. The sequence of events as far
as I can tell:
CreateProcessA(NULL, "regsvr32 comdlg32.ocx",....)
Process_CREATE calls fork_and_exec( NULL, "regsvr32 comdlg32.ocx", ...…
[View More])
This sees there is no explicitly specified filename so inserts wine and --
into the command line (now "wine -- regsvr32 comdlg32.ocx")
Eventually the new process starts with the wine -- regsvr32 comdlg32.ocx as
the command line, so it needs to strip off the inserted fields, and in
PROCESS_InitWine, main_exe_name is correct (path\regsvr32.exe) but the
argc/argv includes these new fields. At the top it states:
(Scheduler/process.c, lines 491/492):
app_argv++; /* remove argv[0] (wine itself) */
app_argc--;
This obviously leaves behine the -- and things go downhill from there
onwards.
Interestingly wine -- regsvr32 comdlg32.ocx works fine, so there must be
command line processing here which doesnt occur during the CreateProcess
route.
Question:
Should fork_and_exec insert the -- into the command line? If it should,
should PROCESS_InitWine check for it, ie:
app_argv++; /* remove argv[0] (wine itself) */
app_argc--;
if (app_argc && strcmp(app_argv[0], "--") == 0) {
app_argv++; /* remove argv[1] ('--' inserted by fork_and_exec) */
app_argc--;
}
However, what implications are of doing this (it works, of course). This
feels like hacking around an imcompatibility within wine but I am happy to
submit a patch as it definitely resolves a problem for me.
Regards,
Jason
[View Less]
On Wed, 1 May 2002, Olivier Houchard wrote:
> Hi,
>
> Here are a few patches.
> The first one is to be applied on dlls/dinput/keyboard/main.c. It is ugly but that's the only way I found to get games that use SetEventNotification for keyboard to work.
> The second one is to be applied on memory/global.c. It is not the best way to get memory size on FreeBSD I guess, but it is still better than 16*1024*1024 :)
Maybe a couple of configure checks would be better?
You could check …
[View More]for sys/sysctl.h and sysctlbyname for instance.
For Linux we cannot check for anything because it uses normal functions
and simply tries to read stuff in /proc. But on FreeBSD, the return of
the first sysctlbyname("hw.physmem"...) may be used as a basis of an if,
placed inside and #ifdef, and before the Linux one.
--
Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/
Advice is what we ask for when we already know the answer but wish we didn't
-- Eric Jong
[View Less]