Re: I/O port access broken (SEH broken)
On Wed, 01 Oct 2003 10:28:03 -0700, you wrote: > Andreas Mohr <[EMAIL PROTECTED]> writes: > > > Unhandled exception: privileged instruction in 32-bit code (0x0040348b). > > In 32-bit mode. > > 0x0040348b (FT255_T32.exe..text+0x248b in FT255_T32.exe): outb %al,%dx > > Wine-dbg> > > > > with a parallel port flash tool I'm trying to use, whereas before it > > used to work with both direct I/O port access and ppdev. > > > > In other words: exception handling about I/O port access has been broken. > > That's the way it's supposed to work under NT. You probably need to > run that app with Windows version set to NT. Logitech PageScan Color software must have the same problem then. It is win-32 code that aceesses the parallell port, it does not run under NT, there is no NT version of the software. It used to run with some unrelated problems under wine. I assume that there is a "deep" reason why win9* compatibility has been dropped here? Rein -- Rein Klazes [EMAIL PROTECTED]
Re: Implementation of GetCompressedFileSize[AW]
On Thu, 2 Oct 2003, [iso-8859-1] Sylvain Petreolle wrote: > Works cool, but you could return INVALID_FILE_SIZE when the function > fails. Maybe. If the patch is not applied, I'll recheck error codes. > OT : Too bad that we dont have GetProcessMemoryInfo, this is what keeps > cygwin programs unable to start into bash. I don't think it's the reason. GetProcessMemoryInfo is not even present on Windows 98, yet bash works on it. It seems that all Cygwin programs think that they are using COM1 as terminal (try "wine tty"). That's most likely the reason why bash exits silently. It even displays the prompt if I give it "-i" but then exits seeing that the terminal is closed. GetProcessMemoryInfo is called after that: <[EMAIL PROTECTED] bin>$ PS1="WINE/BASH> " wine bash.exe -- -i fixme:cdrom:CDROM_GetInterfaceInfo not implemented for true scsi drives fixme:console:SetConsoleCtrlHandler (0x61011400,0) - no error checking or testing yet fixme:console:SetConsoleCtrlHandler (0x61011400,1) - no error checking or testing yet err:dosfs:DOSFS_CreateCommPort Couldn't open device '/dev/ttyS0' ! (check permissions) fixme:dosfs:DOSFS_OpenDevice device open L"COM1" not supported (yet) err:file:CreateFileW Couldn't open device L"com1"! err:comm:GetCommState FILE_GetUnixHandle failed fixme:ntdll:NtQueryObject Unsupported information class 1 err:comm:GetCommState FILE_GetUnixHandle failed fixme:ntdll:NtQueryObject Unsupported information class 1 err:dosfs:DOSFS_CreateCommPort Couldn't open device '/dev/ttyS0' ! (check permissions) fixme:dosfs:DOSFS_OpenDevice device open L"COM1" not supported (yet) err:file:CreateFileW Couldn't open device L"com1"! fixme:comm:ClearCommError no handle (nil) found fixme:comm:ClearCommError no handle (nil) found err:comm:GetCommState FILE_GetUnixHandle failed fixme:comm:ClearCommError no handle (nil) found err:comm:GetCommState FILE_GetUnixHandle failed WINE/BASH> fixme:comm:ClearCommError no handle (nil) found fixme:comm:ClearCommError no handle (nil) found fixme:comm:PurgeComm no handle (nil) found exit fixme:psapi:GetProcessMemoryInfo (hProcess=0x48, 0x408c2bf0, 40): stub <[EMAIL PROTECTED] bin>$ -- Regards, Pavel Roskin
Re: Regression in lstrcmpiA (occurred in late June, NLS related)
On Thu, 2 Oct 2003 12:47, Dmitry Timoshkov wrote: > The source of all of this is the difference between MS and unicode.org > sort weight tables. There is no an easy way to make unicode.org database > look like the MS one unfortunately... Well right now it's not using any table at all - it's just going through to strncmpiW, which is essentially a word-by-word comparison. Presumably the issue now is copyright on the MS version of the table. Do you have anything written down on the differences that you can give me so I can look for work-arounds?
Re: Implementation of GetCompressedFileSize[AW]
> FIXME about GetCompressedFileSizeA was too annoying when running Cygwin > programs, so I implemented it. The code uses st_blocks when possible to > account for sparse files and falls back to st_size if st_blocks is missing > in struct stat. The code uses shift operations so that both systems with > 32-bit and 64-bit off_t will do their best to provide accurate results. Works cool, but you could return INVALID_FILE_SIZE when the function fails. I patched it into win32/newfns.c for long time but never sent a patch. OT : Too bad that we dont have GetProcessMemoryInfo, this is what keeps cygwin programs unable to start into bash. = Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Re: Regression in lstrcmpiA (occurred in late June, NLS related)
"Troy Rollo" <[EMAIL PROTECTED]> wrote: > Yes, but it this also means it worked for ASCII-7. Right now it doesn't even > work for that. This creates problems for some applications, such as those > that incorrectly use lstrcmpA to do binary searches on internal ordered > keyword tables where the keywords can include punctuation characters or > underscores. It means they fail to find some of their keywords, the result > being spurious error results. Since the ASCII-7 range is the same regardless > of character set, this wrong use of lstrcmpA happens to work on Windows if > all the keywords in such a table are limited to that range. The source of all of this is the difference between MS and unicode.org sort weight tables. There is no an easy way to make unicode.org database look like the MS one unfortunately... -- Dmitry.
Re: Regression testing framework
On Thu, 2 Oct 2003, Jakob Eriksson wrote: > The feature requests come in faster now and I also have less time > to work on this stuff for the moment, so I release my little baby into > the wild: Cool, thanx! It needs to be integrated with the rest of the wine build system, maybe a bit of cleanup, etc. I will take care of it. -- Dimi.
Regression testing framework
The feature requests come in faster now and I also have less time to work on this stuff for the moment, so I release my little baby into the wild: Please apply: http://vmlinux.org/jakov/Wine/programs-winetest.tar.gz regards, Jakob
New winetests.exe
New build of winetests.exe with tests from CVS 2003-10-02 http://vmlinux.org/~jakov/Wine/
Re: Regression in lstrcmpiA (occurred in late June, NLS related)
On Wed, 1 Oct 2003 18:25, Dmitry Timoshkov wrote: > > The older behaviour was > > consistent with Win2k. > > ... and only with Latin1 locale, failing with others. Yes, but it this also means it worked for ASCII-7. Right now it doesn't even work for that. This creates problems for some applications, such as those that incorrectly use lstrcmpA to do binary searches on internal ordered keyword tables where the keywords can include punctuation characters or underscores. It means they fail to find some of their keywords, the result being spurious error results. Since the ASCII-7 range is the same regardless of character set, this wrong use of lstrcmpA happens to work on Windows if all the keywords in such a table are limited to that range.
Re: Updated winetests.exe
Dimitrie O. Paun wrote: But I think we are going in the wrong direction here. This is more part of a different project, a porting status (Steven is working on that). Maybe we should drop all this and just focus on tests results, it doesn't make sense to track build status just for some files here, when we're (hopefully) going to do the tracking for the entire tree. Excellent. Lets separate these tasks - that of regr. testing and checking build status! regards, Jakob
Re: Updated winetests.exe
Ferenc Wagner wrote: Fine vision, I am sold on it, although I would like to provide a way to make more frequent builds. I don't have time for more detailed replies just now, but I think more frequent builds would be very good. Otherwise test maintainers would have a very long turnaround time for bug fixes. regards, Jakob
Fix for notepad and winecfg losing focus
Hello! Our notepad has a bug that causes it to lose focus on startup. In order to initialize the new document, WinMain() calls DIALOG_FileNew(), which focuses the editor subwindow. The problem is that it happens before ShowWindow() is called on the main window. As a result, focusing the subwindow causes "activation" of its parent without actually showing it. This leaves the code in dlls/user/focus.c in the confused state. When ShowWindow() is called, the window is not brought to foreground because it's "already active". Then set_active_window() decides to draw the inactive caption because the window is not in foreground. Windows 2000 doesn't show this problem. Notepad and winecfg are focused properly on startup. I think there are many solutions to this problem. For example, the check for visibility could be moved from SetActiveWindow() to the lower-level set_active_window(). The attached patch is minimally intrusive. This decreases its chances of breaking anything, but it may not be the best radical solution. If SetFocus() finds an invisible window while looking for the ultimate parent, it fails. The same is already done for minimized and disabled windows. The patch has been successfully tested in the non-managed and desktop modes. The managed node is not affected because the captions are not shown. Cygwin setup (http:/www.cygwin.com/setup.exe) is also positively affected. === --- dlls/user/focus.c +++ dlls/user/focus.c @@ -258,6 +258,7 @@ HWND WINAPI SetFocus( HWND hwnd ) HWND parent; LONG style = GetWindowLongW( hwndTop, GWL_STYLE ); if (style & (WS_MINIMIZE | WS_DISABLED)) return 0; +if (!(style & WS_VISIBLE)) return 0; parent = GetAncestor( hwndTop, GA_PARENT ); if (!parent || parent == GetDesktopWindow()) break; hwndTop = parent; === -- Regards, Pavel Roskin
Re: uxtheme.dll
On Wednesday 01 October 2003 09:59 am, Steven Edwards wrote: > This is very kickass dude. I concur. I've been fantasizing about looking into this stuff myself, although so far I've always decided I had more pressing matters to look into. But some of this stuff is just so cool... and frankly, wine has a case of the uglies that could use fixing. A little razzle and dazzle can go a long way towards raising the profile of a project. Anyone who's ever subscribed to the goodies-pipeline from StarDock knows -- this stuff has the potential to be very, very pretty. In fact, in my opinion, it made my Windows even prettier than my Linux (although the performance can be pretty awful). And KDE/gnome themes obviously could do something that was never really possible for wine before. So... good luck, I am sure this will be quite difficult, but it's a great idea, in my opinion. -- gmt "Every normal man must be tempted, at times, to spit on his hands, hoist the black flag, and begin slitting throats." -- H. L. Mencken
Re: Does anyone know about WM_SETFOCUS and EN_SETFOCUS
Bill Medland <[EMAIL PROTECTED]> writes: > Are you saying that you believe that the edit control itself sends the > EN_SETFOCUS? Yes, the edit control sends it when it gets a WM_SETFOCUS. That's how all the notification messages work. > Our software includes some tracing and what I see in it suggests that under > Windows there are EN_SETFOCUS messages whereas under Wine they are > WM_SETFOCUS, and I am trying to understand why. Probably the focus is set to the parent window directly instead of being set to the edit control. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Does anyone know about WM_SETFOCUS and EN_SETFOCUS
On October 1, 2003 10:25 am, Alexandre Julliard wrote: > Bill Medland <[EMAIL PROTECTED]> writes: > > Also see the SetFocus documentation that says it sends WM_SETFOCUS. > > > > So maybe they mean that it sends a WM_SETFOCUS unless its an edit control > > in which case it sends EN_SETFOCUS. > > No, it sends a WM_SETFOCUS to the edit control, which in turns sends > an EN_SETFOCUS to its parent. Why doesn't this do the right thing for > you? Are you saying that you believe that the edit control itself sends the EN_SETFOCUS? Our software includes some tracing and what I see in it suggests that under Windows there are EN_SETFOCUS messages whereas under Wine they are WM_SETFOCUS, and I am trying to understand why. -- Bill Medland ACCPAC International, Inc. [EMAIL PROTECTED] Corporate: www.accpac.com Hosted Services: www.accpaconline.com
linuxtag in Dresden, Germany
Hi folks, is there anybody at the linuxtag in Dresden, Germany on Sat. October 18th 2003? I'd like to see you around. Bernhard
Re: winealsa: improve sound quality for IDsDriverImpl
Dimitrie O. Paun wrote: >The best thing to do is to post it here so we can see what we are >talking about... And yes, we all want only the best code for wine :) The code is already submitted in my patch. After thinking twice, I found that the runtime check can be sped up. Calling snd_async_callback_t twice is enough. Because we could commit the whole buffer for the first time, ALSA driver will know the buffer is full. If the buffer will be reallocated, it is the right time for the driver to perform the action. And the new address will be returned next time we call snd_pcm_mmap_begin. We need not wait for the whole buffer to be played once. And I got some new information about the noticeable interval. Seems it's something about the sound data format was not correctly set, for sox -c1 -r44100 -sw /usr/share/sounds/pop.wav -tossdsp /dev/audio && wine winamp has the problem, but sox -c1 -r44100 -sb /usr/share/sounds/pop.wav -tossdsp /dev/audio && wine winamp is unbelievably good. How could it be? I should find out if it's something is wrong with my system or something else. >-- >Dimi.
ssl and kerberos
I need some help with configure.ac. In RH8 and 9, openssl is compiled with krb5 support. The problem comes from the fact that the kerberos files are not under /usr/include, rather /usr/kerberos/include. So when ssl.h includes krb5.h, it can't find it. It'd need to be detected and add /usr/kerberos/include to the list of EXTRAINCL if compiling with only ssl.h is not enough. (I never noticed before because I had recompiled openssl locally to not use kerberos at all, and on the other machine I never looked that closely as everything is installed stock) Once that is fixed, it will trigger another bug in the kerberos part of openssl, namely that FAR is used, but we'll get to that bridge another time. Vincent
Re: I/O port access broken (SEH broken)
Andreas Mohr <[EMAIL PROTECTED]> writes: > Unhandled exception: privileged instruction in 32-bit code (0x0040348b). > In 32-bit mode. > 0x0040348b (FT255_T32.exe..text+0x248b in FT255_T32.exe): outb %al,%dx > Wine-dbg> > > with a parallel port flash tool I'm trying to use, whereas before it > used to work with both direct I/O port access and ppdev. > > In other words: exception handling about I/O port access has been broken. That's the way it's supposed to work under NT. You probably need to run that app with Windows version set to NT. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Does anyone know about WM_SETFOCUS and EN_SETFOCUS
Bill Medland <[EMAIL PROTECTED]> writes: > Also see the SetFocus documentation that says it sends WM_SETFOCUS. > > So maybe they mean that it sends a WM_SETFOCUS unless its an edit control in > which case it sends EN_SETFOCUS. No, it sends a WM_SETFOCUS to the edit control, which in turns sends an EN_SETFOCUS to its parent. Why doesn't this do the right thing for you? -- Alexandre Julliard [EMAIL PROTECTED]
Re: Does anyone know about WM_SETFOCUS and EN_SETFOCUS
On October 1, 2003 12:51 am, Gerhard Gruber wrote: > > Is anyone out there an expert in Windows focus handling? > > > > I have problems with our application and the focus handling in places. > > > > Basically it seems to me that there is some sort of logic in windows > > whereby > > the code calls PostMessage (WM_SETFOCUS) but the result is that the > > parent of > > the target window receives WM_COMMAND EN_SETFOCUS instead. > > > > Does anyone know anything about such translations? > > From MSDN: > > The EN_SETFOCUS notification message is sent when an edit control receives > the keyboard focus. The parent window of the edit control receives this > notification message through a WM_COMMAND message. > > LRESULT CALLBACK WindowProc( > HWND hwnd, // handle to window > UINT uMsg, // WM_COMMAND > WPARAM wParam, // edit control identifier, EN_SETFOCUS > LPARAM lParam// handle to edit control (HWND) > ); > Parameters > wParam > The low-order word specifies the edit control identifier. > The high-order word specifies the notification message. > > lParam > Handle to the edit control. > Remarks > The parent window will always get a WM_COMMAND message for this event, it > does not require a notification mask sent with WM_SETEVENTMASK. > > Rich Edit: For information about the compatibility of rich edit versions > with the various system versions, see About Rich Edit Controls. Thanks for taking the time to reply. Yes, I know about that. Also see the SetFocus documentation that says it sends WM_SETFOCUS. So maybe they mean that it sends a WM_SETFOCUS unless its an edit control in which case it sends EN_SETFOCUS. So what exactly is an edit control. i.e. what is the queriable property that allows us to decide which to send. There is a suggestion that actually this translation is done down in the DefWindowProc somewhere. (See http://groups.google.ca/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=%235vMQagTDHA.1288%40tk2msftngp13.phx.gbl ) I see that currently we don't do anything with WM_SETFOCUS in DefWindowProc. -- Bill Medland ACCPAC International, Inc. [EMAIL PROTECTED] Corporate: www.accpac.com Hosted Services: www.accpaconline.com
Re: Translating WINE using dedicated tools
On October 1, 2003 04:25 am, Martin Quinson wrote: > I would like to help here, but I need to know the gramar of the resource > files. Do you have any parsers around there ? Yes, there is a lex/yacc parser in wrc: http://cvs.winehq.com/cvsweb/wine/tools/wrc/ In particular: http://cvs.winehq.com/cvsweb/wine/tools/wrc/parser.y?rev=1.40&content-type=text/x-cvsweb-markup -- Dimi.
Re: Translating WINE using dedicated tools
> and winehq web site This is if Jeremy Newman wants to have the site translated. As I didn't want to translate anything before being sure it would be accepted I've emaild him various times to know if/how winehq should be translated, and I never got an answer.
Re: Translating WINE using dedicated tools
Le mer 01/10/2003 à 04:25, Martin Quinson a écrit : > [Please CC me, I'm not subscribed to this list] > > Hello, > > I've read in the last Wine KC that you are getting troubles to keep the > translation of wine uptodate. I am pretty well involved in the translation > of free software, and this is a common issue for all of us. It is so common > that I did a program to deal easily with the translation of any kind of > resource. This is called po4a (po for anything), and you can find more > details about this on http://savannah.nongnu.org/projects/po4a and > http://www.nongnu.org/po4a/ . > > The idea is to ease the convertions resource -> po file and then > po -> resource when the translation is done. So, checking if the translation > is uptodate is as easy as used the dedicated tools of the gettext world. > > Po4a is fully modular, and all we have to do to let wine using it is a new > (perl) module to parse it. You can find more details about how to do a > module using `perldoc Locale::Po4a::TransTractor` once the program is > installed. I'm involved in translating Mozilla and Wine to French, and both don't use po files, so you'll have to convince me to use this format (I know it's the standard Unix way and that there are some tools for it). > > I would like to help here, but I need to know the gramar of the resource > files. Do you have any parsers around there ? The better would be to have > Perl based ones, since this is the language used in po4a. There's a bison/lex one (check in tools/wrc/*.y). Don't know how to modify it, and don't know Perl either :) Basically, what we need is both a way of knowing that everything has been translated (included in the various language files), and then making sure it's still uptodate (tracking modifications between master versions). At least, that's the way we do it for Mozilla. Vincent
Re: Updated winetests.exe
On October 1, 2003 06:25 am, Ferenc Wagner wrote:
> "Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> Why? The current simple scheme of setting it to the date
> should work if we do not build twice in 24 hours. If that
> is not enough, we can include a full CVS time specification
> down to seconds, as I said, it is a simple tag, not parsed,
> not used for anything except matching.
Well, normally we should build on official releases, as it
avoids confusion: we have well known files, etc. to refer to.
I agree with you that we should have a way to do intermediate
releases, but if we do them we should mark them somehow (that
should be easy to do). For official releases we can't just use
the current date, simply because Alexandre may do the release
at night (say 23:00, as he usually does), and we will not get
around to it until the next day. Granted, non of these are
real problems, I'm just saying we need to be careful how we
label things so we can make sense of them when we look back.
> Yes, it should include the full CVS date then, not a big
> deal. Yeah, when summarizing an offical release, I can
> provide LXR links as an extra.
Even for non-official builds we should have the CVS version
of the file (IF the file was not modified in the build tree),
so we can provide cvsweb links there as well.
> Well, the trick is in the compile_file_with_* routines. The
True. Let's reorganize things a bit:
make -s #build the entire tree under Linux
for dll in $DLLS; do
wine dlls/$dll/tests/$dll_test.exe.so
for file in dlls/$dll/tests/*.c; do
ver=`cvs status $file | grep Working | awk '{print $3}'`
echo " * $file $ver"
done
done
for build in $BUILD_SYSTEMS; do
echo "*** Build: $build"
make -s $build 2>$build.errors #don't take this to literal :)
cat $build.errors
done
This should be doable, and parsable, right?
> > we really need to automate the build procedure, I don't
> > think manual stuff will cut it.
>
> Can do with MinGW, for sure. But for MSVC??
We don't need to _ship_ different binaries. All we need to make
sure is that tests build. If we can't do that for MSVC, then
too bad, so sad -- we can't get stuck there. But there is a simple
way to do the MSVC build: AFAIK cl.exe works under Wine, so we
can have targets in the Makefiles that build with that. So what
we need is an installed MSVC, an version of Wine that is _known_
to run cl.exe just fine, and a bit of elbow grease.
But I think we are going in the wrong direction here. This is more
part of a different project, a porting status (Steven is working on
that). Maybe we should drop all this and just focus on tests results,
it doesn't make sense to track build status just for some files here,
when we're (hopefully) going to do the tracking for the entire tree.
> Fine vision, I am sold on it, although I would like to
> provide a way to make more frequent builds.
For sure, that should be fairly simple, all we have to make
sure is we do a decent job with the labels.
--
Dimi.
Re: Translating WINE using dedicated tools
Once wine has final docs this would be great, the wine docs will change before 1.0 (The wine-user docs are config-file orientated, and many other things may change before 1.0), the wine-devel docs don't really need translating as most developers know English, and the wine programs and dlls can be translated manually without any difficulty, but once we have a final version of wine user docs and winehq web site this tool could be very useful.
Re: I/O port access broken (SEH broken)
> "Andreas" == Andreas Mohr <[EMAIL PROTECTED]> writes: Andreas> Hi all, sounds like the recent architectural changes were a bit Andreas> too much: now I get Andreas> Unhandled exception: privileged instruction in 32-bit code Andreas> (0x0040348b). In 32-bit mode. 0x0040348b Andreas> (FT255_T32.exe..text+0x248b in FT255_T32.exe): outb %al,%dx Wine-dbg> Andreas> with a parallel port flash tool I'm trying to use, whereas Andreas> before it used to work with both direct I/O port access and Andreas> ppdev. Andreas> In other words: exception handling about I/O port access has Andreas> been broken. Another related problem: I need inport/outport in some private VXD reimplementation too. The reimplementation resided in my win32/device.c file. Do I need to do LoadLibrary(winedos) GetProc(xxx,"Inport") in my code now? Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
WWN back issues unavailable
Hi, I am not sure whom to tell, that In the bottom of the WWN Back Issues page on WineHQ the "Next 12 Issues" link does not really work. Feri.
Re: Updated winetests.exe
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> On Tue, 30 Sep 2003, Ferenc Wagner wrote:
>
>> I thought the build tag (which can be any one-line string)
>> was enough. Why do we need anything else?
>
> That works nicely IF Jakob builds the tests only on official
> releases
Why? The current simple scheme of setting it to the date
should work if we do not build twice in 24 hours. If that
is not enough, we can include a full CVS time specification
down to seconds, as I said, it is a simple tag, not parsed,
not used for anything except matching.
> (which should happen anyway).
Why, again?
> In fact, the build script can be smart enough to notice if
> we're not using an offcial release, and provide a
> different build tag.
Yes, it should include the full CVS date then, not a big
deal. Yeah, when summarizing an offical release, I can
provide LXR links as an extra.
>>> -- a simple to generate format would be: [...]
>
> It can't be that hard: we mainly have to
>for dll in $DLLS
> echo "*** $dll"
> ver=`cvs status $file | grep Working | awk '{print $3}'`
> for file in dlls/$dll/tests
> echo " * $file $ver"
> echo "MinGW:"
> compile_file_with_MinGW
> echo "MSVC:"
> compile_file_with_MSVC
> done
> wine dlls/$dll/tests/$dll_test.exe.so
>done
Well, the trick is in the compile_file_with_* routines. The
MinGW way is specified in the Makefiles, how would you
incorporate them? The MSVC way is in the .dsp-s, which is
even worse. Then you can not invoke $dll_test.exe.so,
because MinGW results in $dll_crosstest.exe while MSVC in
something else again. One more thing, although the present
build system ensures (AFAICT) that every .c file corresponds
to a test, it may not forever be the case. And errors are
more frequent in the linking phase anyway.
So, what I find reasonable is capturing the whole make
output in a file for every unit, and publishing it on the
condition that the make fails. It would be easy for MinGW
and possibly impossible for MSVC, I do not have a clue about
that. Sad to say this. Also this is the reason I mentioned
tar. Not for the reports, but for the master files, which
could avoid the mailing list anyway. To be honest, I fail
to see the point of the mailing list. These reports are
rather unsuitable for human consumption (strictly IMO).
> we really need to automate the build procedure, I don't
> think manual stuff will cut it.
Can do with MinGW, for sure. But for MSVC??
> In fact, the build procedure should be included in our
> makefiles, and we can invoke it automatically on a new
> Wine release through the make_release script...
Fine vision, I am sold on it, although I would like to
provide a way to make more frequent builds.
Feri.
Translating WINE using dedicated tools
[Please CC me, I'm not subscribed to this list] Hello, I've read in the last Wine KC that you are getting troubles to keep the translation of wine uptodate. I am pretty well involved in the translation of free software, and this is a common issue for all of us. It is so common that I did a program to deal easily with the translation of any kind of resource. This is called po4a (po for anything), and you can find more details about this on http://savannah.nongnu.org/projects/po4a and http://www.nongnu.org/po4a/ . The idea is to ease the convertions resource -> po file and then po -> resource when the translation is done. So, checking if the translation is uptodate is as easy as used the dedicated tools of the gettext world. Po4a is fully modular, and all we have to do to let wine using it is a new (perl) module to parse it. You can find more details about how to do a module using `perldoc Locale::Po4a::TransTractor` once the program is installed. I would like to help here, but I need to know the gramar of the resource files. Do you have any parsers around there ? The better would be to have Perl based ones, since this is the language used in po4a. What do you guys think? Mt. [Please CC me, I'm not subscribed to this list] -- The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" (I found it!) but "That's funny ..." --- Isaac Asimov pgp0.pgp Description: PGP signature
Re: uxtheme.dll
This is very kickass dude. I think this is the right method of supporting themes for WINE. KDE can already do GTK themes with a little bit of tweaking so it will support both Linux Desktops and GTK themes are now supported under Windows with GTK-Win32 so maybe we can even use this in ReactOS when its ready. Thanks Steven --- James Gregory <[EMAIL PROTECTED]> wrote: > Some time ago I started hacking in support for GTK themes. When I > first > suggested this project to the list there was suggestions that doing > it > with uxtheme.dll was the way to go. I agreed, but didn't have winxp > to > play with, so I kept tinkering on this project with the intent of > learning a bit more about how wine works (which meant learning a lot > about how GDI and X works, though I didn't realise that I'd need to > know > that stuff when I started on the project). I actually managed to get > some results which were starting to look promising (though there's no > way I'd submit that code as a patch). Screenshots here (the checkbox > being the only important part): > > http://james.id.au/wine/wine-ss1.png > http://james.id.au/wine/wine-ss2.png > http://james.id.au/wine/wine-ss3.png > > Anyway, the reason I'm posting is not to suggest that this code be > used > (nor the approach I took), but to mention that if theming code is to > be > written that I think it's really important to have a way to pass off > rendering of controls etc to a .so that can be dlopened and called > with > dlsym. IIRC the existing system uses a function lookup table, so > there > shouldn't be much that needs to change for this to occur -- only the > initialisation of this function table and probably some hooks so that > these .sos can detect whether or not they'll work with the current > configuration (as an example the way I was doing gtk theming won't > work > with anything that isn't x11drv. I don't like breaking encapsulation > like this, but it sounds like it's practical in this case). I don't > know > if I can be of any help, but I'm interested in trying -- please keep > me > posted. > > James. __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
Re: "Start menu" (continued ...)
Just a thought which may or may not be completely out of proportion: In which sense can Wine and native Desktop be easily synchronized? I see a number of problems such as who should synchronize to whom. Why make an arbitrary Unix desktop synchronize to a Wine start menu? Why not the other way around? Wine builds in all other areas on top of the existing Unix platform. Is it really useful to start to base the native Unix desktop on Wine? Or is this the first step in getting Wine as yet another Unix desktop into the picture? I am not talking about a complete desktop, just about a little submenu in your K-menu, or Gnome menu, or whatever menu one could be using. Such a thing already exists, but is implemented with scripts instead of with a Wine deamon/linux client. The current system does not seem to be to flexible. Therefore, I suppose that a setup with wine deamon as a server and a linux client would be better. For example: one could easily add support for more desktop environments, without the changing the deamon. Robert
I/O port access broken (SEH broken)
Hi all, sounds like the recent architectural changes were a bit too much: now I get Unhandled exception: privileged instruction in 32-bit code (0x0040348b). In 32-bit mode. 0x0040348b (FT255_T32.exe..text+0x248b in FT255_T32.exe): outb %al,%dx Wine-dbg> with a parallel port flash tool I'm trying to use, whereas before it used to work with both direct I/O port access and ppdev. In other words: exception handling about I/O port access has been broken. Andreas Mohr
Re: Regression in lstrcmpiA (occurred in late June, NLS related)
"Troy Rollo" <[EMAIL PROTECTED]> wrote: > When lstrcmpiA was moved from ole2nls.c to locale.c, (around 28th June) the > results of comparisons in some cases became reversed. For example, the > underscore now returns as greater than alphabetic characters, whereas it used > to return as less than alphabetic characters. Yes, I'm aware of the problem. Current CX Office CVS has fixes for all the differences we have found so far. Unfortunately a proper fix requires a change of the unicode sort weight tables generated automatically from the unicode.org data base and we (Alexandre, me, other people at Codeweavers) don't know yet how to make it fit with future imports from unicode.org. Unicode weight tables from MS and unicode.org have huge amount of differences in many absolutely unexpected places... > The older behaviour was > consistent with Win2k. ... and only with Latin1 locale, failing with others. -- Dmitry.
Re: "Start menu" (continued ...)
Robert van Herk <[EMAIL PROTECTED]> >As I understand, right now there are various "standards" on how to write >menus for Linux, that are incompatible. That would mean that writing a >"grand unified ;-)" start menu client as I discussed before is currently >impossible. > >What could be made already though, is a Wine deamon that talks to >shell32.dll internally and input/outputs with pipes to some linux >client, in order to serve the start menu items. This would link the >Windows start menu to Linux, in a tidy way. So the idea is that the >Windows program's output could be piped to some Linux client that >actually creates the menu dynamically, so it stays in continuous >synchronization with your Start menu directory. > > >Would such a system be appreciated by the you people? Or do you think I >should wait untill a better standarization is available? Or do you think >creating a Windows deamon and a Linux client is too much overkill for >such a feature? > >Also, if this feature would be handy, does anyone have expirience with >the KPanelAppMenu? I can't get the thingy to work yet... Just a thought which may or may not be completely out of proportion: In which sense can Wine and native Desktop be easily synchronized? I see a number of problems such as who should synchronize to whom. Why make an arbitrary Unix desktop synchronize to a Wine start menu? Why not the other way around? Wine builds in all other areas on top of the existing Unix platform. Is it really useful to start to base the native Unix desktop on Wine? Or is this the first step in getting Wine as yet another Unix desktop into the picture? Also the Wine start menu will usually contain mostly Windows or Winelib apps, I suppose. The Unix desktop would have to treat those entries accordingly, makeing proper distinction between them and native unix apps/scripts or whatever which of course shouldn't be a real problem. Maybe this has been discussed already in depth and I missed it? Rolf Kalbermatter
Re: Regression in lstrcmpiA (occurred in late June, NLS related)
Further investigation reveals another problem in lstrcmpiA: MSDN documents
this function as executing what it describes as a "word sort", which results
in the words "co-op" and "coop" sorting to the same place. This is almost a
correct description of what happens (if the strings come out to be the same
after the word sort it appears that it does a regular comparison as well).
The attached files demonstrate the divergence of wine in this regard as well
as the original regression.
#include
#include
char *test_strings1[] =
{
"_",
"A",
"a",
"z",
"Z",
0
};
char *test_strings2[] =
{
"coop",
"co-op",
"co-op a",
"coop a",
"co-op b",
"coop b",
0
};
void
test_string(char *pch, char **test_strings)
{
char **ppch = test_strings;
while (*ppch)
{
printf("%s\t%s\t%d\n", pch, *ppch, lstrcmpiA(pch, *ppch));
++ppch;
}
}
void
do_test(char **test_strings)
{
char **ppch = test_strings;
while (*ppch)
test_string(*ppch++, test_strings);
}
int
main(int argc, char **argv)
{
do_test(test_strings1);
do_test(test_strings2);
return 0;
}
_ _ 0
_ A -1
_ a -1
_ z -1
_ Z -1
A _ 1
A A 0
A a 0
A z -1
A Z -1
a _ 1
a A 0
a a 0
a z -1
a Z -1
z _ 1
z A 1
z a 1
z z 0
z Z 0
Z _ 1
Z A 1
Z a 1
Z z 0
Z Z 0
coopcoop0
coopco-op -1
coopco-op a -1
coopcoop a -1
coopco-op b -1
coopcoop b -1
co-op coop1
co-op co-op 0
co-op co-op a -1
co-op coop a -1
co-op co-op b -1
co-op coop b -1
co-op a coop1
co-op a co-op 1
co-op a co-op a 0
co-op a coop a 1
co-op a co-op b -1
co-op a coop b -1
coop a coop1
coop a co-op 1
coop a co-op a -1
coop a coop a 0
coop a co-op b -1
coop a coop b -1
co-op b coop1
co-op b co-op 1
co-op b co-op a 1
co-op b coop a 1
co-op b co-op b 0
co-op b coop b 1
coop b coop1
coop b co-op 1
coop b co-op a 1
coop b coop a 1
coop b co-op b -1
coop b coop b 0
_ _ 0
_ A 1
_ a 1
_ z 1
_ Z 1
A _ -1
A A 0
A a 0
A z -1
A Z -1
a _ -1
a A 0
a a 0
a z -1
a Z -1
z _ -1
z A 1
z a 1
z z 0
z Z 0
Z _ -1
Z A 1
Z a 1
Z z 0
Z Z 0
coopcoop0
coopco-op 1
coopco-op a 1
coopcoop a -1
coopco-op b 1
coopcoop b -1
co-op coop-1
co-op co-op 0
co-op co-op a -1
co-op coop a -1
co-op co-op b -1
co-op coop b -1
co-op a coop-1
co-op a co-op 1
co-op a co-op a 0
co-op a coop a -1
co-op a co-op b -1
co-op a coop b -1
coop a coop1
coop a co-op 1
coop a co-op a 1
coop a coop a 0
coop a co-op b 1
coop a coop b -1
co-op b coop-1
co-op b co-op 1
co-op b co-op a 1
co-op b coop a -1
co-op b co-op b 0
co-op b coop b -1
coop b coop1
coop b co-op 1
coop b co-op a 1
coop b coop a 1
coop b co-op b 1
coop b coop b 0
Re: Does anyone know about WM_SETFOCUS and EN_SETFOCUS
> Is anyone out there an expert in Windows focus handling? > > I have problems with our application and the focus handling in places. > > Basically it seems to me that there is some sort of logic in windows > whereby > the code calls PostMessage (WM_SETFOCUS) but the result is that the parent > of > the target window receives WM_COMMAND EN_SETFOCUS instead. > > Does anyone know anything about such translations? >From MSDN: The EN_SETFOCUS notification message is sent when an edit control receives the keyboard focus. The parent window of the edit control receives this notification message through a WM_COMMAND message. LRESULT CALLBACK WindowProc( HWND hwnd, // handle to window UINT uMsg, // WM_COMMAND WPARAM wParam, // edit control identifier, EN_SETFOCUS LPARAM lParam// handle to edit control (HWND) ); Parameters wParam The low-order word specifies the edit control identifier. The high-order word specifies the notification message. lParam Handle to the edit control. Remarks The parent window will always get a WM_COMMAND message for this event, it does not require a notification mask sent with WM_SETEVENTMASK. Rich Edit: For information about the compatibility of rich edit versions with the various system versions, see About Rich Edit Controls.
Regression in lstrcmpiA (occurred in late June, NLS related)
When lstrcmpiA was moved from ole2nls.c to locale.c, (around 28th June) the
results of comparisons in some cases became reversed. For example, the
underscore now returns as greater than alphabetic characters, whereas it used
to return as less than alphabetic characters. The older behaviour was
consistent with Win2k.
The output below is from the following source:
---begin test program---
#include
#include
char *test_strings[] =
{
"_",
"A",
"a",
"z",
"Z",
0
};
void
test_string(char *pch)
{
char **ppch = test_strings;
while (*ppch)
{
printf("%s\t%s\t%d\n", pch, *ppch, lstrcmpiA(pch, *ppch));
++ppch;
}
}
int
main(int argc, char **argv)
{
char **ppch = test_strings;
while (*ppch)
test_string(*ppch++);
return 0;
}
---end test program---
---Wine output from immediately before the change---
_ _ 0sorts
_ A -1
_ a -1
_ z -1
_ Z -1
A _ 1
A A 0
A a 0
A z -1
A Z -1
a _ 1
a A 0
a a 0
a z -1
a Z -1
z _ 1
z A 1
z a 1
z z 0
z Z 0
Z _ 1
Z A 1
Z a 1
Z z 0
Z Z 0
---End---
---Wine output from immediately after the change---
_ _ 0
_ A 1
_ a 1
_ z 1
_ Z 1
A _ -1
A A 0
A a 0
A z -1
A Z -1
a _ -1
a A 0
a a 0
a z -1
a Z -1
z _ -1
z A 1
z a 1
z z 0
z Z 0
Z _ -1
Z A 1
Z a 1
Z z 0
Z Z 0
~---End---
Re: uxtheme.dll
On Wed, 2003-10-01 at 12:21, Kevin Koltzau wrote: > I'm aware of the scope of the project. The general design of uxtheme lends > itself well to being done incrementally, eg. controls could be modified as > support for the particular control is implemented, etc. > Also part of the API are a few functions (IsThemeActive & IsAppThemed) which > will allow themes to be disabled in the beginning for theme aware > applications until sufficient support has been built or if themes are > disabled via config/registry. Some time ago I started hacking in support for GTK themes. When I first suggested this project to the list there was suggestions that doing it with uxtheme.dll was the way to go. I agreed, but didn't have winxp to play with, so I kept tinkering on this project with the intent of learning a bit more about how wine works (which meant learning a lot about how GDI and X works, though I didn't realise that I'd need to know that stuff when I started on the project). I actually managed to get some results which were starting to look promising (though there's no way I'd submit that code as a patch). Screenshots here (the checkbox being the only important part): http://james.id.au/wine/wine-ss1.png http://james.id.au/wine/wine-ss2.png http://james.id.au/wine/wine-ss3.png Anyway, the reason I'm posting is not to suggest that this code be used (nor the approach I took), but to mention that if theming code is to be written that I think it's really important to have a way to pass off rendering of controls etc to a .so that can be dlopened and called with dlsym. IIRC the existing system uses a function lookup table, so there shouldn't be much that needs to change for this to occur -- only the initialisation of this function table and probably some hooks so that these .sos can detect whether or not they'll work with the current configuration (as an example the way I was doing gtk theming won't work with anything that isn't x11drv. I don't like breaking encapsulation like this, but it sounds like it's practical in this case). I don't know if I can be of any help, but I'm interested in trying -- please keep me posted. James. > On Tuesday 30 September 2003 02:21 am, Roderick Colenbrander wrote: > > I hope you know what you will begin with. (For the ones that don't know > > uxtheme.dll is the dll that takes care of all theming on WinXP and it is > > the dll that dlls like comctl32 and all others use for theming) > > > > Some time ago I checked out uxtheme.dll a bit and it seems that it needs > > changes all over Wine. As I understand it WinXP ships with two sets of > > comctl32.dll and friends. One is the "old" version and one is a new uxtheme > > aware version. The uxtheme aware version contains lots of changes and uses > > uxtheme for theming. To use uxtheme you need to add uxtheme support to the > > dlls that need it which looks like a huge job. Perhaps this is something > > post Wine-1.0? > > > > Roderick Colenbrander > >
