Re: [ANN] Conformance testing campaign
Ferenc Wagner wrote:
Greetings!
Hereby I ask people who have access to real Windows machines
to help me gather information about the behaviour of cross-
compiled conformance tests on the different platforms.
Please go to http://afavant.elte.hu/~wferi/wine for details.
If you can build the tests in the Wine tree by MSVC, then
packaging the compiled binaries would also mean a valuable
addition. You will also find a packaging script on the page.
Thanks for your time,
Feri.
On Windows 2003 server, one of the tests actually created a GPF (cannot
write to memory address 0x).
In any case - attached are the results. I'll probably only get around to
compiling them on VC Sunday.
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Tests from build 20030829
advapi32.dll:registry (test 1)
registry.c:97: Test failed: value set to 'xx' instead of 'Te'
registry.c:98: Test failed: data set to 'xxx' instead of 'foobar'
registry.c:112: Test failed: data set to 'xxx' instead of 'foobar'
registry: 56 tests executed, 0 marked as todo, 3 failures.
advapi32.dll:registry done
comctl32.dll:dpa (test 2)
dpa: 4 tests executed, 0 marked as todo, 0 failures.
comctl32.dll:dpa done
dsound.dll:dsound (not compiled)
dsound.dll:propset (not compiled)
gdi32.dll:generated (test 3)
generated: 3892 tests executed, 0 marked as todo, 0 failures.
gdi32.dll:generated done
kernel32.dll:alloc (test 4)
alloc: 58 tests executed, 0 marked as todo, 0 failures.
kernel32.dll:alloc done
kernel32.dll:atom (test 5)
atom: 229398 tests executed, 0 marked as todo, 0 failures.
kernel32.dll:atom done
kernel32.dll:codepage (test 6)
codepage: 2 tests executed, 0 marked as todo, 0 failures.
kernel32.dll:codepage done
kernel32.dll:console (test 7)
console: 275 tests executed, 0 marked as todo, 0 failures.
kernel32.dll:console done
kernel32.dll:directory (test 8)
directory: 51 tests executed, 0 marked as todo, 0 failures.
kernel32.dll:directory done
kernel32.dll:drive (test 9)
drive: 160 tests executed, 0 marked as todo, 0 failures.
kernel32.dll:drive done
kernel32.dll:environ (test 10)
environ: 39 tests executed, 0 marked as todo, 0 failures.
kernel32.dll:environ done
kernel32.dll:file (test 11)
file.c:265: Test failed: couldn't create file "testfi/" (err=123)
file.c:524: Test failed: CopyFileA: unexpected error 80
file.c:556: Test failed: CopyFileW: unexpected error 80
file.c:585: Test failed: CREATE_NEW should fail if file exists and last error value
should be ERROR_SUCCESS
file.c:611: Test failed: CREATE_NEW should fail if file exists and last error value
should be ERROR_SUCCESS
file.c:623: Test failed: DeleteFileA(NULL) returned ret=0 error=3
file.c:627: Test failed: DeleteFileA("") returned ret=0 error=3
file.c:639: Test failed: DeleteFileW(NULL) returned ret=0 error=3
file.c:643: Test failed: DeleteFileW("") returned ret=0 error=3
file.c:799: Test failed: FindFirstFile on Root directory should Fail
file.c:806: Test failed: Bad Error number 2
file.c:679:Current offset = 0015
file.c:708:Current offset = 0015
file: 487281 tests executed, 0 marked as todo, 11 failures.
kernel32.dll:file done
kernel32.dll:format_msg (test 12)
format_msg: 58 tests executed, 0 marked as todo, 0 failures.
kernel32.dll:format_msg done
kernel32.dll:generated (test 13)
generated.c:542: Test failed: TYPE_ALIGNMENT(*(LPWIN32_STREAM_ID)0) == 8 (expected 4)
generated: 842 tests executed, 0 marked as todo, 1 failure.
kernel32.dll:generated done
kernel32.dll:locale (test 14)
locale.c:155: Test failed: GetTimeFormat got '' instead of '4'
locale.c:156: Test failed: GetTimeFormat: got 1 instead of 2
locale.c:182: Test failed: GetTimeFormat got '8.@:56AM' instead of '8.@:56.@:AM'
locale.c:183: Test failed: GetTimeFormat: got 9 instead of 12
locale.c:191: Test failed: GetTimeFormat got '' instead of '3'
locale.c:192: Test failed: GetTimeFormat: got 1 instead of 2
locale.c:467: Test failed: GetDateFormat got '5/4/2002' instead of '5/4/02'
locale.c:468: Test failed: GetDateFormat: got 9 instead of 7
locale.c:490: Test failed: GetDateFormat check DATE_YEARMONTH with null format
expected ERROR_INVALID_FLAGS got return of '10' and error of '0'
locale: 193 tests executed, 0 marked as todo, 9 failures.
kernel32.dll:locale done
kernel32.dll:path (test 15)
path.c:514: Test failed: GetLongPathNameA: wrong return code, 112 instead of 48
path.c:904:TMP=C:\DOCUME~1\ADMINI~1.SUN\LOCALS~1\Temp
path.c:915:TMP=C:\WINDOWS
path.c:925:TMP=C:\
path.c:935:TMP=C:
path: 1733 tests executed, 0 marked as todo, 1 failure.
kernel32.dll:path done
kernel32.dll:pipe (test 16)
pipe.c:591:test 1 of 4:
pipe.c:593:test 2 of 4:
pipe.c:595:test 3 of 4:
pipe.c:511:test_NamedPipe_2 starting
pip
Re: Viruses in the wine-devel archive ??
P. Christeas wrote:
Marcus Meissner wrote:
On Fri, Aug 22, 2003 at 06:13:39PM +0300, P. Christeas wrote:
Yup, here is the message.
http://winehq.com/hypermail/wine-patches/2003/08/0203.html
I'll remove that attachment. Should we contact that author and let him
know he is infected, or simply remove him from the list?
Btw. Does SoBig.F run under wine? If yes, how bad can it get?
It crashes for me.
Ciao, Marcus
OK, we 'll fix wine .. ;)
On the serious side: wine could actually be the perfect platform for security
tests. Having a virus spread on a pseydo-system is noteworthy..
We've been through this discussion before too. Wine is not a VM, and the
isolation between Win32 and Unix code is the result of application's
ignorance, rather than a deliberate design decision. As such, it is
highly NOT recommended for cases where hostile code of unknown qualities
is tested.
For all you know, sobig may be checking whether it is runnning on wine,
and then issuing the correct interrupts (static linking dlopen) and
infecting your Unix system.
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Re: When will Wine integrate an x86 CPU emulator?
Francois Gouget wrote: PS: Please accept my apologies if this was a joke. No, not a joke. I plead temporary insanity. It does sound saner to let use double interfaces, or to emulate the Wine code itself. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: When will Wine integrate an x86 CPU emulator?
To add to Jim's idea: What if the entire Wine code runs natively, but in little endian (possibly for winelib too - that would actually help with binary compatibility between the Unix and the windows versions of programs)? If this sounds absured to you, then you have never done TCP/IP programming ;-) This way, the conversions are avoided, and only performed when you have to communicate with the underlying OS. Converting integers for inside use cannot be, no matter what you do, as inefficient as emulating the entire instruction set. Shachar Jim White wrote: Francois Gouget wrote: On Wed, 20 Aug 2003, Ulrich Weigand wrote: [...] The only reason for wanting to integrate an emulator into Wine is that this would allow to run the Wine components natively, and only switch to the emulator for executing Windows binaries. [...] Not only it would be extremely complex but I am not even sure it would be more efficient. ... How does that apply to the emulator case? Well, let's take InflateRect: ... I don't understand why you put effort into shooting down strawmen. If you are not interested in a version of Wine incorporating an x86 emulator then that's just dandy. The point of integrating the x86 emulation is not necessarily to get into the interface between Wine and the Windows applications. The point is to avoid a whole layer of OS emulation. I have no problem even with the idea that some of Wine's code remains x86 in order to avoid switching modes excessively. Consider Mac OS X. Using Wine for x86/Linux means running a second OS under emulation and an attendant extra file/device mapping layer. Also while it is obvious that an intermediate stage will be to use X, a futher improvement could be to use the native toolkit. And especially attractive from the x86 emulator's standpoint is the ability to identify read-only code resources with defined entry points that can be JIT compiled to native code rather than simply interpreting. The opportunities for doing that at the machine level for hosting an OS are much more limited. So while integrating x86 emulation with Wine certainly adds another whole set of complexity, the performance gains are easily attained because of the reduction in emulation layers which can readily run into order-of-magnitude performance penalities in all kinds of places as you illustrated. Anyhow, I realize that the Wine-devel list isn't the most hospitable place for these sorts of ideas. That's why I set up http://darwine.sf.net. And there is no conflict here. Wine has more than a big enough chunk of work carved out for itself, and it is it's sucess there that brings the attention from other perspectives with interests in leveraging that value into other areas. We have a strong common interest in free and open software. Otherwise we'ld just buy Windows (and for Mac OS X, Virtual PC). Jim -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: is anyone running windows 95, windows 98, windows ME or windows2003?
Jonathan Wilson wrote: If so, I need you to run some kind of PE dumper that can dump exports (such as dumpbin from MS with the /exports switch on user32.dll and gdi32.dll from your version and send me the results, along with details of which version of windows you are running. I want this info because I am compiling a list of the different versions of windows and which functions are exported by user32.dll and gdi32.dll in each version. I still have 2003 installed. What do I run, and who do I send the output to? Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: wrong keyboard layout
Dmitry Timoshkov wrote: "Shachar Shemesh" <[EMAIL PROTECTED]> wrote: BTW, what wrong happens if your keyboard was misdetected? In the current CVS all national characters should work fine regardless what keyboard layout was detected. Is that only a warning message which makes you worry? Does this also apply to UTF-8? I, for one, still can't get any characters recognized when the locale is UTF-8. Shachar, Raul, could you apply the attached patch and produce a log for me? Run Wine notepad with +x11drv,+key,+keyboard,+event, press some offending keys, compress the log and send it directly to me with good description what is expected and what you really get. After some messing around, and kind help from Dimitry, the problem was that my locale was not set correctly. Setting the locale to en_US.UTF-8 (with the dash, and in upper case) works with both wine and xev. Any other combination (utf8, UTF8, etc.) works with konsole, openoffice, kedit, and just about any other program I tested, but not with wine and xev. You live and you learn, obviously. There is one thing that still bothers me. When using right-win for group toggle, I get a "`" printed when switching from group 0 to group 1, and ";" when switching from group 1 to group 0. Otherwise, everything works fine. This does not happen when other combinations are used to switch modes (well, both shifts toggle used to drive wine simply mad, I don't know how things are today, but that also happened with some other applications). Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: wrong keyboard layout
Dmitry Timoshkov wrote: "Phil Krylov" <[EMAIL PROTECTED]> wrote: XFree86 -version reports: XFree86 Version 4.3.0 Release Date: 27 February 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.22_pre2-gss i686 [ELF] Build Date: 23 July 2003 The log you asked for is attached. It's rather big, so I truncated it after ToUnicode entries. Here is your problem: trace:x11drv:x11drv_init_thread_data Using C locale of Input Method XFree86 uses C locale, not UTF-8 one. As I wrote previously, test with 'xev' first. As soon as it starts to work, Wine should work as well. I have asked you this before in private, but I fear I didn't really understand the answer. When I ran with an "incorrect" locale setting (en_US.utf8 instead of en_US.UTF-8), konsole would display Hebrew characters using the UTF-8 encoding. Furthermore, running OpenOffice, kedit or Mozilla would also work properly. It appears as if wine and xev are the only two applications in the world that would refuse to work with those slightly incorrect locales. Can you please explain again how the other applications do this miracle? Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: winver
Vincent Béron wrote: Le mer 13/08/2003 à 01:40, Shachar Shemesh a écrit : Windows 2003 Standard Edition (let me know if you want another edition): Majour Version: 5 Minor Version: 2 Build Number: 3790 Platform ID: 2 CSDVersion empty (NULLs) ServicePackMajor: 0 ServicePackMinor: 0 Reserved: 272, 3 Thanks Shachar, but there's still something I'm not sure about. After ServicePackMinor, our winbase.h defines the following fields: WORD wSuiteMask BYTE wProductType BYTE wReserved I suppose your winbase.h only had two WORD wReserved(1,2)? If that's the case, wSuiteMask maps to 272 (VER_SUITE_SINGLEUSERTS|VER_SUITE_TERMINAL), and wProductType to VER_NT_SERVER. That would be our first version advertised as VER_NT_SERVER. Is there a workstation version of 2K3, as earlier NT versions were always defined as that in Wine? Vincent Windows 2003 comes in three flavours, apparently. Web edition, Standard Edition and Enterprise Edition. All three are considered "Windows 2003 Server". There is no "Windows 2003 Pro", "Home", "Workstation" or whatever. In that respect, yes, it does make sense. The headers I was using are the standard ones that come with Visual Studio 6 SP5. If the struct is supposed to have extra parameters, I have not seen them (I used the debugger's ability to spread a struct's content - I'm lazy that way). If there is some source you want to send me to run, please let me know. I tested everything on Windows 2003 server standard edition. I can install the web or the enterprise editions, but I'm afraid the setup took over an hour for this one, and I actually need it for some testing. If it's really crucial to you, I'll try to install it on a virtual machine (will probably be faster than my PII 233 160MB machine that installed this version). Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: winver
Vincent Béron wrote: Le ven 01/08/2003 à 13:02, Shachar Shemesh a écrit : [EMAIL PROTECTED] wrote: I've noticed that wine doesn't yet seem to have a winver option for windows server 2003, I suppose it a trivial thing to implement, at least by seeing how quickly this was done for windows xp. If anyone needs to run regression tests on Windows 2003 Server, I can lay my hands on one (and many other, if needed) Could you just send the result of GetVersionExA? I think I have everything else (at least to define the version...) Vincent Windows 2003 Standard Edition (let me know if you want another edition): Majour Version: 5 Minor Version: 2 Build Number: 3790 Platform ID: 2 CSDVersion empty (NULLs) ServicePackMajor: 0 ServicePackMinor: 0 Reserved: 272, 3 -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: wrong keyboard layout
Dmitry Timoshkov wrote: "Shachar Shemesh" <[EMAIL PROTECTED]> wrote: There is one thing that still bothers me. When using right-win for group toggle, I get a "`" printed when switching from group 0 to group 1, and ";" when switching from group 1 to group 0. Otherwise, everything works fine. This does not happen when other combinations are used to switch modes (well, both shifts toggle used to drive wine simply mad, I don't know how things are today, but that also happened with some other applications). That's because we should ignore some key events. Try the attached patch, perhaps some other keysyms should be added to that list. Raul, that should help you as well. Yes, that solves it for me. Thanks, Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
bidi support test program
Hi all,
Attached is a simple program to test whether the Win32 API supports BiDi
reordering. Some packagers asked me for such a utility in the past, so
they can make sure that their inclusion of ICU worked, and without
forcing them to actually understand languages that are all Hebrew to them.
I'm not sure whether it would be necessary to include this utility
inside the Wine soure, or how to do so. This is not exactly a test, as a
failure is totally justified under some circumstances.
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
/*
* Copyright (C) 2003 Shachar Shemesh
*
* 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
#include
const WCHAR simple_bidi[]={0x5d0, 0x5d1, 0x5d2, 0};
int main()
{
WCHAR reordered_bidi[5];
HDC dc=GetDC(NULL);
GCP_RESULTSW results={ sizeof(GCP_RESULTSW), reordered_bidi, NULL, NULL, NULL, NULL,
NULL, 0, 0 };
/* Try to reorder the simple string, and see if things come out the right way */
GetCharacterPlacementW( dc, simple_bidi, 3, 0, &results, GCP_REORDER );
if( reordered_bidi[0]==0x5d2 )
{
printf("Success\n");
} else
{
printf("Failed\n");
}
return 0;
}
Re: wrong keyboard layout
Dmitry Timoshkov wrote: BTW, what wrong happens if your keyboard was misdetected? In the current CVS all national characters should work fine regardless what keyboard layout was detected. Is that only a warning message which makes you worry? Does this also apply to UTF-8? I, for one, still can't get any characters recognized when the locale is UTF-8. When trying to type "Shalom" in notepad, wine makes a political statement: Could not stat /cdrom (No such file or directory), ignoring drive D: Could not stat /dvd (No such file or directory), ignoring drive G: err:keyboard:X11DRV_ToUnicode Please report: no char for keysym 0CF9 (hebrew_shin) : err:keyboard:X11DRV_ToUnicode (virtKey=41,scanCode=1E,keycode=26,state=2010) err:keyboard:X11DRV_ToUnicode Please report: no char for keysym 0CEC (hebrew_lamed) : err:keyboard:X11DRV_ToUnicode (virtKey=4B,scanCode=25,keycode=2D,state=2010) err:keyboard:X11DRV_ToUnicode Please report: no char for keysym 0CE5 (hebrew_waw) : err:keyboard:X11DRV_ToUnicode (virtKey=55,scanCode=16,keycode=1E,state=2010) err:keyboard:X11DRV_ToUnicode Please report: no char for keysym 0CED (hebrew_finalmem) : err:keyboard:X11DRV_ToUnicode (virtKey=4F,scanCode=18,keycode=20,state=2010) Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: winver
[EMAIL PROTECTED] wrote: I've noticed that wine doesn't yet seem to have a winver option for windows server 2003, I suppose it a trivial thing to implement, at least by seeing how quickly this was done for windows xp. If anyone needs to run regression tests on Windows 2003 Server, I can lay my hands on one (and many other, if needed) Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Work for hire^H^H^H^Hgrade
Steven Edwards wrote: Even at that if I had the time, know-how, was in school and could get credit for working on a open source project I would not work on WINE but port User Mode Linux to Windows. The Line project already has a elf loader that will let you run Linux apps in Cygwin so its adapting that UML and doing a port for a Mingw target. I just think it would be really nice to be able to run Linux on top of a NT kernel so if ReactOS is ever ready you guys could have Linux on top of a kernel running NT/2K drivers. Thanks Steven Actually, I know someone who started to port UML to the win32 platform. Mandatory military service in Israel meant that this project is on hold, but if Ronen wants to pick that one up, I can hook him up with the person. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Work for hire^H^H^H^Hgrade
Hi all, A prof. in a locale university is doing a summer course about open source development. I gave them a short power point lecture (on Linux :-), and showed them IE running, and managed to hook one vulenteer to do his assignment in Wine. I have managed to interest him in some of open issues that are close to my heart (i.e. - BiDi related issues). However, this is far from final. I'm sure he would love to hear about other interesting areas, but some criteria must be kept. It must be a task that is moreorless self contained (he is supposed to be graded for it at the end), and it must be something known to be possible in a reasonable amount of hours (i.e - it can't be "implementing MSI"). Then again, it can't be something too trivial (i.e. - not "localize notepad"). Currently at hand are adding encoding selection to the font dlg (and making it ANSI call Unicode in the process), and adding BiDi to the edit control. If you feel you have something else that may be of interest to him, feel free to try and grab him away :-) Shachar P.S. No, I have not dropped of the face of the planet, and I still read this list. Just too busy to be doing anything useful (except hiring other working hands, which may count for something, I guess). I'll be back, though. -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: wine/programs/notepad rsrc.rc main.h main.c di ...
--- wine/programs/notepad/rsrc.rc:1.8 Mon Jul 21 20:38:52 2003
+++ wine/programs/notepad/rsrc.rc Mon Jul 21 20:38:52 2003
@@ -24,6 +24,20 @@
#include "commctrl.h"
#include "notepad_res.h"
+ID_ACCEL ACCELERATORS
+{
+"^A", CMD_SELECT_ALL
+"^C", CMD_COPY
+"^F", CMD_SEARCH
+"^O", CMD_OPEN
+"^S", CMD_SAVE
+"^V", CMD_PASTE
+"^X", CMD_CUT
+"^Z", CMD_UNDO
+VK_F3, CMD_SEARCH_NEXT, VIRTKEY
+VK_F5, CMD_TIME_DATE, VIRTKEY
+}
+
#include "Da.rc"
#include "De.rc"
#include "En.rc"
What's the sense in making the accelerators global to all languages?
Each language has it's own accelerator keys (just as it has it's own menus).
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Re: Problam compiling wine rpm with icu support
puoti wrote:
I've just installed icu 2.6 on a fresh install of Mandrake Linux 9.1, and was
compiling wine-20030709 when I noticed a configure message saying
checking if we can staticly link icu... no
and I'm wondering what I've done wrong. Should I try with icu 2.4, or must I
compile icu with some special option? Please help, for various reasons this
month's wine rpm for mandrake is already very late.
Sorry for the late reply. I'm CCing the mailing list, in case someone
there has a better clue as to the problem.
Can you please send me the config.log file?
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Re: Warning on Alpha Linux
Todd Vierling wrote: On Sat, 19 Jul 2003, Vincent Béron wrote: : That's an easy one. One an Alpha, sizeof(int) != sizeof(foo *). I think : sizeof(int) == 8, while sizeof(foo *) == 4. Other way round. sizeof(int) == 4; sizeof(void *) == 8. : gcc is kind enough to warn you about this potentially nasty situation, : although in these particular cases I don't see how putting the pointer : in something larger will create a problem. Use intptr_t. If that's not available (via autoconf test), typedef intptr_t to be "unsigned long" locally, as "long" is the size of a pointer on all typical ILP32 and LP64 hosts. The reason something is a warning and not an error is that it MAY have a legitimate use. As such, there should always be a way to change the code so that it will keep the same meaning, but will avoid the warning in the future. In this particular case, for example, what does applying the following change do? -if (!((int)id >> 16)) return wine_dbg_sprintf( "", (int)id & 0x ); +if (!((int)id >> 16)) return wine_dbg_sprintf( "", (UINT16)id ); I'm a bit confused. gcc seems to be warning us about an explicit cast? I always thought that, in C, explicit casts are THE way of avoiding compile time warnings. Why should one change the semantic meaning of the code just so that gcc is pacified? Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: something I could work on, can someone tell me if this is somethingusefull or not?
Jonathan Wilson wrote: I could take the WINE implementation of notepad.exe (which is clearly a "clone" of an older version of notepad, probobly from Windows 98 or ME or 2000 or something) and add to it so it does the same things or similar things as the windows XP notepad. Some of the differences between XP notepad and Wine notepad: the file size limit is gone (because microsoft re-wrote the edit control to not have a size limit I guess) the "page setup" and "print setup" dialogs are combined into one dialog now with new code to handle that. A few slight differences between the UI of both (for example the Cut and Copy items are disabled if there is nothing selected, something wine notepad doesnt do) Wrap Ling Lines (in Wine notepad) is moved to a new Format menu in Windows XP notepad and is called Word Wrap. Also, the Font menu item is moved for the Format menu. Find and Find Next are moved to the Edit menu and renamed from Search and Search Next. Also, a Replace option and a Go To option (goes to a specific line) have been added. And, the Save and Save As dialogs have an "encoding" selection box that lets you select And, the print function has a "now printing" dialog. Also (obviously), the help system is better in Windows XP notepad. Basicly, I plan to implement some of these things (but I wont do the help system since thats something I know nothing about) to make wine notepad more like windows XP notepad (in particular, adding the Replace and Go To features) I am taking this on because I want to improve my skills at working with the Win32 API. Basicly, I want to know: 1.is this something usefull to the Wine project? and 2.is there anything I should avoid doing for whatever reason? (for example, are there things I cant do because they would violate MS IP or something) As far as I'm concerned, you left out the most important thing WinXP's notepad does, which is that it is unicode. That's the most important improvment missing. You are welcome to put in your additions (though the 64K limitation, if it indeed exists in Wine's notepad, should be fixed at the Edit control level, and not notepad). There is no explicit attempt, however, to mimic notepad for Windows, just it's functionality, where apropriate. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Locales with the same language
Dmitry Timoshkov wrote: "Vincent Béron" <[EMAIL PROTECTED]> wrote: (after a bit more testing) Using only SUBLANG_FRENCH_CANADIAN will display in French on both Windows and Wine. Using only SUBLANG_FRENCH_SWISS will display in English on both Windows and Wine. Using only SUBLANG_FRENCH will display in French only in Windows, English in Wine (with LANG=fr_CA). So SUBLANG_FRENCH seems to act (on Windows) the same way as a wildcard, matching any of it's sublanguages if an exact match can't be done. Could you please elaborate a bit, how exactly you did the tests above? I also tried defining more than one (ie, SUBLANG_FRENCH and SUBLANG_FRENCH_CANADIAN) resources. On Windows it chose the SUBLANG_FRENCH, while in Wine it chose the SUBLANG_FRENCH_CANADIAN. That gets me a bit puzzled though... unless my installation of Windows is set to French, then French Canadian as a fallback (don't know of to check this). All of this highly depend on the exact language set in your system (be it Windows or Wine). I've attached my test app. See the results I got eclosed there between #if 0/#endif. Note, that if your system doesn't support SetThreadLocale() (i.e. you are running Win9x), the system will prefer your current locale settings instead of the provided value and it will influence behaviour of LoadString and FindResource. As you might see, Wine doesn't behave exactly like Windows, Wine makes a preference for the current locale, Windows prefers to choose LANG_ENGLISH first. As it was discussed previously, Wine's behaviour have to stay as it is now, otherwise all NLS support for built-in DLLs and apps will broke. I suspect that this depends on the language of Windows you install. When I have some time, I'll play a bit with this. MS also has a version of windows called "MUI", or Multilinugual User Interface. I suspect that that version behaves more like Wine does at the moment, but I have not checked that one either. In the mean while, let's indeed reverese the patch translating SUBLANG_NEUTRAL->SUBLANG_DEFAULT. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Locales with the same language
Dmitry Timoshkov wrote: "Shachar Shemesh" <[EMAIL PROTECTED]> wrote: Then probably you had to replace SUBLANG_NEUTRAL by SUBLANG_DEFAULT only for LANG_ENGLISH resources. Anyway the patch I just set adds LANG_ENGLISH,SUBLANG_NEUTRAL to the fallback list, since my test under win2k shows that. After some more analysis as a result of our discussion, maybe that is, indeed, the right thing to do. I then proceeded to research what the situation on Windows was, and the categorical answer was that Visual Studio would not let you create resources with SUBLANG_NEUTRAL. SUBLANG_DEFAULT was the only option. It is for that reason that I believe that SUBLANG_NEUTRAL should only be used as a search qualifier, never as an actual resource. If VS wouldn't allow you to add Hebrew resources you would decide that Hebrew language is forbidden in resources? VS DOESN'T let me add Hebrew resources, but if I then go and type in the language ID manually, it accepts it. On the other hand, it didn't accept SUBLANG_NEUTRAL as a valid option. As I said earlier in this mail, further research seems to suggest that I was, indeed, wrong. The MSDN is a little hazy on the subject of SUBLANG_NEUTRAL. It has always been my understanding that we should be treating SUBLANG_NEUTRAL as a wildcard. Is that wrong? The best way is to write a test program. I did it. Did you? At the time, yes. The result was that LANG_ENGLISH, SUBLANG_DEFAULT was selected no matter what I did. When I have the time (yeah, right) I'll try installing a few variants of the same windows versions and do comparative assesment. I'm willing to mark this down as a bad case of memory on my part, in any case. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Locales with the same language
Dmitry Timoshkov wrote:
Then the correct will be change all resources with SUBLANGE_DEFAULT to
SUBLANG_NEUTRAL until someone localize them?
I can modify this if is the correct.
Actually there was a completely opposite patch committed recently:
2003-01-05
Shachar Shemesh <[EMAIL PROTECTED]>
Change the SUBLANG_NEUTRAL clause in all winelib applications to
SUBLANG_DEFAULT, as they should be.
I vote to revert that patch.
Then perhaps I should explain why I submitted this patch.
The problem was with notepad. If my locale said "he_IL", it would
display the menues in Danish. The reason was that, failing to find
Hebrew locales, and failing to find LANG_ENGLISH, SUBLANG_DEFAULT
locales, it loaded the first one available.
I then proceeded to research what the situation on Windows was, and the
categorical answer was that Visual Studio would not let you create
resources with SUBLANG_NEUTRAL. SUBLANG_DEFAULT was the only option. It
is for that reason that I believe that SUBLANG_NEUTRAL should only be
used as a search qualifier, never as an actual resource.
Now, looking at the code searching path I see:
/* 2. specified language with neutral sublanguage */
pos = push_language( list, pos, MAKELANGID(
PRIMARYLANGID(info->Language), SUBLANG_NEUTRAL ) );
As far as my understanding goes, this should match the LANG_FRENCH with
ANY sublang. Why doesn't this rule correctly find LANG_FRENCH,
SUBLANG_FRENCH_CANADIAN? The MSDN is a little hazy on the subject of
SUBLANG_NEUTRAL. It has always been my understanding that we should be
treating SUBLANG_NEUTRAL as a wildcard. Is that wrong?
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Re: [RESENT]: Fixed winedbg example configuration
Eric Pouech wrote: These are two separate changes: a) Wine's registry needs to preserve ordering (c++ builder, presumably among others) b) BiGgUn wants to reorder the winedbg lines for some reason. I'm not saying he's right (I don't understand why he wants to reorder things like that), but I am saying that if he is wrong, it's not because this would be reordered anyway. Basically, I'm not supporting his patch, I'm saying Alexandre's reason for rejection is wrong. I still agree with Alexandre here. Order of keys in registry doesn't matter when loading, moreover, next time wine exits, the keys get automatically reordered (and saved), so I don't understand the need of the key reordering. A+ It appears that several Windows programs expect the order of the keys to remain the same as the order of creation. One such program is modern Explorer, which reorders menus by rewriting the registry. I believe we will eventually have to support that. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Locales with the same language
Dmitry Timoshkov wrote: "Vincent Béron" <[EMAIL PROTECTED]> wrote: I have problems displaying Wine's app in my locale (fr_CA). They seem to prefer to go to the English locale, although if launched with LANG=fr_FR wine notepad they will obey the French locale. LANG=fr wine notepad will display a warning about the plurality of locales with "fr", but will display the app in French nonetheless. LC_ALL=fr_CA wine notepad Nope, doesn't work. That's because there is no resources marked as (LANG_FRENCH,SUBLANG_FRENCH_CANADIAN) in the Wine apps. If you fairly confident that all flavours of French (including Canadian) have too little differences and creating separate resources for each of them isn't worth the effort, then a way to go is to mark all french resources in Wine with (LANG_FRENCH,SUBLANG_NEUTRAL). No, that doesn't sound correct to me. Did you check that this is the way Windows does it's matching? As far as I remember, if an exact match does not exist, we should look for the same language with sublang DEFAULT. IIRC, there is no situation where defining "SUBLANG_NEUTRAL" is the correct thing to do in resources. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Shellexecute, bug 22, and MSDN
Dustin Navea wrote: So should this be filed as a bug or would it be too difficult to implement a check for the proper verb? Just copy this email into Bugzilla. Excellent bug report. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Word in Hebrew and Wine
Dmitry Timoshkov wrote: "Shachar Shemesh" <[EMAIL PROTECTED]> wrote: I tried it and it does NOT work. I still get "unrecognized keyboard event". I'd prefer to see at least a +key,+keyboard,+x11drv,+event log (compressed) with good description: what exactly doesn't work. I get "unknown key". I'll try to recompile with it and let you know. Please bear in mind that knowing which keyboard locale the current keymap belongs to is important. Actually that's not important for internal functionality in current limits, but it's necessary for keyboard layout APIs. And it is important for getting Word to work with BiDi. All I was trying to do is to get this aspect of the API a higher priority. I'm not sure we can afford to give the locale info from the keyboard layouts just yet. In future we need to revive LCID for every defined keyboard layout, as it was some time ago. That's what I meant. Sorry if I wasn't clear. What exactly part of it you see could be simplified, and how? I was aiming for the following path: 1. Detect current keymap. Try to do that independantly for each keymap group (i.e. - have an array - group0 - US, group1 - IL, group2 - RU). The keys will be stored inside the keyboard map in Unicode. I'm not 100% sure how to do that stage yet, but I do have a relatively non-efficient way of doing that to fall back to, if necessary. This will require major revamping of the current code. If you have an idea or a preliminary patch I'm interested to see it. I have already started collecting the necessary information. It does, however, require relying on Xkb. This would also let us let applications control the current layout (for that I already have a working code). I /THINK/ we can get to a point where we don't need the keyboard lists in keyboard.c at all, which means we can support new keyboards with a simple line saying "IL is LCID(MAKELANG(LANG_HEBREW, SUBLANG_DEFAULT))". I still have not started looking at how difficult it would be to be softly dependant on Xkb (so that if it's not present, not to support Windows keyboard switching). On the whole, however, I'm getting the feeling I'm planning work to be done in parallel to you, which sounds like a waste of resources. Especially as I may have found a local vulenteer to do the actual coding :-). If it makes more sense for you to delve into this, let me know and I'll redirect my vulenteer to other useful areas of Wine. 2. Trap the X events that notify about group changes, and pass them on as Windows messages to applications. That's a part of the planned keyboard layout support implementation. Good 3. When an X event arrives, convert the raw virtual key to a raw Windows key, and pass it on. Do not convert to ASCII, ANSI, or any other non-layout information. In essence, the keyboard mapping is not used at this stage at all. 4. When an application asks to convert the raw Windows key to ANSI/Unicode, look up the result in the current keymap. #3 and #4 are exactly how it's currently implemented. That's not the impression I got, I have to admit. It has been a while since I stepped through the code, but I got the impression that Windows raw key is derived from the keyboard location of the ANSI representation of the X raw key. When I have the time again (not this week, I'm afraid), I'll have a look again. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Word in Hebrew and Wine
Hi all, I think I found what is needed in order to implement my suggested keyboard support. The only drawback is that it requires the use of XKB, which is not a given in all Xservers. Personally, I find it hard to believe that there are many X servers that don't support it (the extension is from 1997). Anyone has anything to say in terms of policy? Suggestions? Shachar Shachar Shemesh wrote: I was aiming for the following path: 1. Detect current keymap. Try to do that independantly for each keymap group (i.e. - have an array - group0 - US, group1 - IL, group2 - RU). The keys will be stored inside the keyboard map in Unicode. I'm not 100% sure how to do that stage yet, but I do have a relatively non-efficient way of doing that to fall back to, if necessary. 2. Trap the X events that notify about group changes, and pass them on as Windows messages to applications. 3. When an X event arrives, convert the raw virtual key to a raw Windows key, and pass it on. Do not convert to ASCII, ANSI, or any other non-layout information. In essence, the keyboard mapping is not used at this stage at all. 4. When an application asks to convert the raw Windows key to ANSI/Unicode, look up the result in the current keymap. Saving the conversion to ANSI and back should detach us some way from the current Unix locale. In particular, I want Unicode Windows applications to work, with the same level of non-regard to current locale as they have on Windows. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Yet again ... Looking for services ...
Steven Edwards wrote: All the machinery for the services seem's to be in wine, so I am wondering if there has been any attempts ? There has been discussion but nothing attempted yet. I think the plan was to add support to wineboot. Thanks Steven This does not fit in with where wineboot is expected to run at the moment. If/when we find a way to run it on startup, adding serivces to it may make sense again. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Known Wine ToDo's
I guess my opinion would be to remove bullet 3 (WCMD), and change bullet 4 (which will now be 3) to "Add localization to more languages and more parts of Wine". Just one quick question - when was it that I became holy keeper of the national language support? I have to know those things, as I'm trying to keep an up to date resume on, and such a title is bound to land me more free-lancer jobs :-). Shachar Tom wrote: Shachar Shemesh wrote: Sylvain Petreolle wrote: National Language Support Finish WCMD translation (i am working on it for the French part) Why isn't that included under the "Add localization to more languages" bullet? How about this... You send a full list of known "National Language Support" ToDo's and a order of priority. And if no one objects that is how they will be listed :) Tom Are all other parts of Wine already localized to all the languages currently supported? -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Known Wine ToDo's
Sylvain Petreolle wrote: National Language Support Finish WCMD translation (i am working on it for the French part) Why isn't that included under the "Add localization to more languages" bullet? Are all other parts of Wine already localized to all the languages currently supported? -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Word in Hebrew and Wine
Dmitry Timoshkov wrote:
Actually Alexandre didn't like that patch, and I reworked it and sent to
wine-patches as "Add support for CP_UNIXCP". If you could try it and
report whether it allows you to type with UTF-8 locale, it would be nice.
I tried it and it does NOT work. I still get "unrecognized keyboard event".
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Re: Word in Hebrew and Wine
Dmitry Timoshkov wrote: Actually Alexandre didn't like that patch, and I reworked it and sent to wine-patches as "Add support for CP_UNIXCP". If you could try it and report whether it allows you to type with UTF-8 locale, it would be nice. Compiling it as we speak. Please bear in mind that knowing which keyboard locale the current keymap belongs to is important. I'm not sure we can afford to give the locale info from the keyboard layouts just yet. Once this patch is commited, all the base for keyboard layout support should be in place, and implementing kbd layout APIs should be a straightforward enough task. I hope. Like I said - the above point is blocking a major application for me. Regarding the current implementation, I don't think that it's over complicated. We have to cope with different virtual key code layouts and should make an attempt to detect current X keyboard layout in order to assign correct keyboard map, and report correct VK_xxx key events. I'm in agreement thus far. I (sadly) don't think the rows of keymap definitions can be tossed out the door just yet. The CP_UNIXCP patch simplifies a bit current scheme by removing the codepage field from layout tables, which should avoid converting X key events to unicode using wrong code page, Well, that may be the case, and yet I think we will need to know the LANGUAGE for the keyboard anyhow. and therefore make it possible to make international keyboard input work even if we have made a mistake while detecting an X keyboard layout. That's actually not what I'm worried about. The last time that the keyboard detection algorithm question was raised, the concensus was that while the current algorithm is sub-ideal, there is no practical need to replace it. What exactly part of it you see could be simplified, and how? I was aiming for the following path: 1. Detect current keymap. Try to do that independantly for each keymap group (i.e. - have an array - group0 - US, group1 - IL, group2 - RU). The keys will be stored inside the keyboard map in Unicode. I'm not 100% sure how to do that stage yet, but I do have a relatively non-efficient way of doing that to fall back to, if necessary. 2. Trap the X events that notify about group changes, and pass them on as Windows messages to applications. 3. When an X event arrives, convert the raw virtual key to a raw Windows key, and pass it on. Do not convert to ASCII, ANSI, or any other non-layout information. In essence, the keyboard mapping is not used at this stage at all. 4. When an application asks to convert the raw Windows key to ANSI/Unicode, look up the result in the current keymap. Saving the conversion to ANSI and back should detach us some way from the current Unix locale. In particular, I want Unicode Windows applications to work, with the same level of non-regard to current locale as they have on Windows. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Word in Hebrew and Wine
Hi, I have a pretty good estimate of what needs to be done to get Word supported in Hebrew. The current problems have to do with Word calling "GetKeyboardLang" after each character, and using the result as a basis for interpreting each received character. Currently, this function just returns the system locale, which causes Word to assume each and every letter is a Hebrew one, even the English ones. The results are pretty catastrophic, as people have reported (typing "Hi there everyone" typically results in the screen showing "Hthere everyone i", with "yone" highlighted with green to say it has syntax correction to suggest. The correct is to replace "there" with "they're"). I have been itching to do an overhaul of the Wine keyboard handling for some time. I think the current scheme is overly complicated, and causes problems. This is a major task, but I may be able to recrute some local help. I am a bit worried, however, about the fact that some other people may also working on a similar task at the moment. I know Dmitry said in the past he is rennovating the keyboard a little, and I know codeweavers still hold a patch that will allow UTF-8 input locale to work. I would like to coordinate the effort. If anyone is working on the keyboard right now, please let me know. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Various problems- it just gets worse!
Duane Clark wrote: Shachar Shemesh wrote: Duane Clark wrote: I do understand the aversion to scripts, but the wineinstall one is fairly mild. I've been using Wine for more than 3 years and have even done some development on it (I wish I had more time for that... sigh). Still, if I want to test with a clean install, I delete or move the old windows and .wine directories and just use wineinstall to create fresh versions. Because, well, it just works so well and is a lot easier than doing the configuration by hand. My beef with wineinstall is that there is no way to isolate the configuration creation part from the install part. I think we should have a script that does only the configuration, fake root and registry creation. This way, the script can be bundled with the package and placed on the destination machine. such a script should be runnable without the sources dir (maybe by specifying the location of the template registry and such via command line, maybe created by ./configure). This way, the order CAN be "./configure, make depend, make, make install, createconf" for normal install. Packagers can then do "./configure --templatedir=/usr/share/wine --prefix=/usr (etc) && make depend && make && TMPDIR=/tmp/winerpmroot make install", and run "createconf" from the "postinstall" section of the RPM sort of thing. Opinions? It sounds like you are looking for something useful for binary distributions. I think that wineinstall would normally only be used by someone who is downloading and installing their first source distribution. Not entirely true either. I often find myself seeking to restore the config. Also, what about someone who downloaded the sources and installed wine system wide, and then wants to enable wine for a second user? So I think wineinstall is appropriate for that. For binary distributions, I think a GUI tool is more appropriate. And there exists a tool, winesetuptk, for that purpose. It is a long time since I tried that tool, but as I recall, it was fairly easy to use. I disagree, even had I been looking for something useful for a binary distribution. A GUI tool would be the worst solution possible. winesetuptk is excellent for an end user trying to tweak his own configuration. Something that runs while rpm -i (or dpkg -i) cannot depend on GUI, for it would prevent it from running while installing the system. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Known Wine ToDo's
Tom wrote: Hello Shachar, I am going to update the ToDo page : http://www.winehq.com/?page=status_todo And im wondering if you can send me a list of ToDo's that your aware of ? Thanks Tom The tasks I'm talking about here are long term. Not all of them have been discussed on wine-devel yet. I'm CCing wine-devel in case anyone wants to object. National Language Support - Remove "Hebrew and Arabic" - it's just part of BiDi if technology is what wer'e talking about. If interface localization is what wer'e talking about, then just add "add localization to more languages". As a subitem of keyboard support, add "allow using a keyboard with keys outside the current locale codepage". Tools - Add "perform Windows' reboot operations automatically when required". Under "Low priority" add "Windows ACL support". -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Bidi B patch
Alexandre Julliard wrote: Shachar Shemesh <[EMAIL PROTECTED]> writes: First I want to clarify something. Nothing in this email is meant to suggest that I think the bidi change should, in any way, depend on this issue. If you want, I can even amend my patch. Yes please. Wilco. Only because we add "-I." to the compilation flags. Adding "-I." to the compilation flags should not be necessary. It is necessary, this has been discussed before. I'll try to find the discussion (if someone has a handy pointer - it would be greatly apretiated), but if it turns out that it is necessary because we use "" instead of <>, I don't think that counts ;-) In any case, it makes much sense to me not to place non-exported headers in include. The idea is that you can tell packagers to take the entire "include" directory and ship it. Unless I misunderstand, and winelib apps actually NEED gdi.h, we do not wish to have it packaged. This leaves packagers with zen decisions - not a good thing. gdi.h will be moved to dlls/gdi at some point. Which of course means that if we do things the way you suggest we then need to go back into all files and change <> back to "". No. It just means we shouldn't change it to <>, now or ever. The fact is that all our source files use "" for both internal and exported headers, and we are not going to change all of them. Why not, really? Because it isn't broken. We need to fix exported headers to use <> since it can make a difference in Winelib apps that use them; but in Wine source files "" works just as well as <>. Ok, how about if I send you a perl program that goes over the wine include folder, searches for each file found there in the MS SDK, and builds a list of exported headers. It will then go over the wine source, and change only those headers from "" to <>. This way, no manual work, no changing "" to <> and then back (as gdi.h will, obviously, not be in that list), and we have a clear consistant policy that makes sense. This also solves the winelib problem you mentioned. Alexandre, I only partially agree. I think the current situation, where "" and <> behave the same, is an undesireable one. We want to be able to tell packagers to grab the entire /include directory with no fear (libwine-devel.rpm anyone?). Yes, include/ should contain only exported headers, it's part of the dll separation work, we are getting there. It's completely orthogonal to whether we use <> or "" to include them. I can see why you say that, but I feel it narrows the discussion down to technical (will or will not compile) consideration only. I think that we also need to show commitment to separating inner from exported, and this, to me, means the source too. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Bidi B patch
First I want to clarify something. Nothing in this email is meant to suggest that I think the bidi change should, in any way, depend on this issue. If you want, I can even amend my patch. Alexandre Julliard wrote: Shachar Shemesh <[EMAIL PROTECTED]> writes: The reason I did was to reduce confusion. The usual includes are standard includes, and can be included with either <> or "". The new include (gdibidi.h) is a local include, and can only be included with "". To differentiate the two, I changed those who could afford a <>. Local includes can be included with <> too, Only because we add "-I." to the compilation flags. Adding "-I." to the compilation flags should not be necessary. there's no reason to make a distinction. Well, there is the minor point of "what do I mean by...". I don't think semantic hints are something to be discarded so easily. And some of the headers in include/ are actually internal, like gdi.h (actually I would argue that bidi definitions should go there). I placed them under the GDI directory, following what I thought was someone else's example. As chance would have it, I don't know what was that. In any case, it makes much sense to me not to place non-exported headers in include. The idea is that you can tell packagers to take the entire "include" directory and ship it. Unless I misunderstand, and winelib apps actually NEED gdi.h, we do not wish to have it packaged. This leaves packagers with zen decisions - not a good thing. The fact is that all our source files use "" for both internal and exported headers, and we are not going to change all of them. Why not, really? I made the original change under the recollection that changing them all was, in fact, the future plan. As such, I though I'll mark this particular file as "already translated", so that they know not to change "gdibidi.h", and thus break compilation. Changing only a few here and there creates a lot more confusion than it solves. Alexandre, I only partially agree. I think the current situation, where "" and <> behave the same, is an undesireable one. We want to be able to tell packagers to grab the entire /include directory with no fear (libwine-devel.rpm anyone?). We don't want it to hold directories not available for the standard windows. In order to enforce this distinction, we need to remove the "-I." from the compilation options. The last stage, of changing "" to <> can then happen slowly. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Bidi B patch
Alexandre Julliard wrote: Shachar Shemesh <[EMAIL PROTECTED]> writes: -#include "config.h" -#include "wine/port.h" +#include +#include #include #include #include -#include "winerror.h" -#include "winnls.h" -#include "wownt32.h" -#include "gdi.h" -#include "wine/unicode.h" -#include "wine/debug.h" +#include +#include +#include +#include +#include +#include +#include "gdibidi.h" Please don't change include quotes when modifying a file. It's not necessary, and only adds confusion. The reason I did was to reduce confusion. The usual includes are standard includes, and can be included with either <> or "". The new include (gdibidi.h) is a local include, and can only be included with "". To differentiate the two, I changed those who could afford a <>. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: win.ini _3_ bounced and I have no idea why ????????????????
Quoting Tom <[EMAIL PROTECTED]>: > I am in favor of a bounced patch list ... And how this would work > is.. in short > if Alexandre thinks someones patch sucks he would re-direct it to a > bounced list > and a very short answer why he thinks it sucks.. Then we would > know if our patch is on que > or on the sucks list :)) And why he thinks it should be there . > > Then no one woul'd have to wonder !! Well only wonder how to fix our > crapy patch so it will get excepted > the next time that is.. > > Anyone have any comments ? > > Tom Two comments: A. While I agree this would create a pleasenter environment for the patch submitters, this would not solve the problem of forgotten patches. You will still not be able to "launch and forget" your patches, as they may simply be overlooked by mistake. B. Any scheme that looks solely at the benefit to one side, but requiring extra work from another side, is really not up to us to decide upon. If Alexander believes he is up to forwarding to such a list, this list will happen. If Alexander thinks this is more work than he is capable of, he won't. In any case, I believe the subject only comes up after Alexander takes a vacation, and patches pile up. I think a simple policy where Alexander PROMISES that he will send a short email saying "as far as I'm concerned, all patches submitted more than 48 hours ago have been processed" will let us all know that this is the time to search for our patch in the latest CVS, and decide whether to resubmit, fix and resubmit, or ask for reasons for the reject. I don't think a reject list is necessary for the standard case. Shachar
Re: win.ini _3_ bounced and I have no idea why ????????????????
Tom wrote:
Hi,
Okay it looks as if my last win.ini patch bounced
may I ask why ?
If there is a problem with it I will be more than glad to
send a patch to fix it.
I just need to know what is wrong with it.. I know
the second one was a little over done :) but what is wrong with this
one ??
last patch =
http://www.winehq.org/hypermail/wine-patches/2003/06/att-0147/01-win.ini_3_.diff
Tom
Hi,
I /THINK/ Alexander has not finished handling his backlog yet. I know I
have some patches that I'm still waiting to see them go in, and a patch
that I have already given up on, that suddenly got merged. I just wish
Alexander would commit to saying "my backlog is now clear - let me know
if anything is missing", which would make us all a bit easier on the
patch list.
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
UTF-8 keyboard?
d:X11DRV_ToUnicode Found keycode 45 (0x2D) trace:keyboard:X11DRV_ToUnicode NumLockMask = 0010 trace:keyboard:X11DRV_ToUnicode AltGrMask = 2000 trace:keyboard:X11DRV_ToUnicode Found keycode 30 (0x1E) trace:keyboard:X11DRV_ToUnicode NumLockMask = 0010 trace:keyboard:X11DRV_ToUnicode AltGrMask = 2000 trace:keyboard:X11DRV_ToUnicode Found keycode 32 (0x20) That is - no errors, but I don't get any characters on screen either. When running this with locale he_IL, I get this: trace:keyboard:X11DRV_KEYBOARD_DetectLayout detected layout is "Israeli keyboard layout" trace:keyboard:X11DRV_InitKeyboard OEM specific virtual key DF assigned to keycode 54: trace:keyboard:X11DRV_InitKeyboard (FF9D (KP_Begin) FFB5 (KP_5) 0 (NoSymbol) 0 (NoSymbol) ) trace:keyboard:X11DRV_InitKeyboard OEM specific virtual key E0 assigned to keycode 73: trace:keyboard:X11DRV_InitKeyboard (FFEB (Super_L) FFEB (Super_L) 0 (NoSymbol) 0 (NoSymbol) ) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0xfe08 trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0xfe08 trace:keyboard:X11DRV_InitKeyboard OEM specific virtual key E1 assigned to keycode 75: trace:keyboard:X11DRV_InitKeyboard (FF67 (Menu) FF67 (Menu) 0 (NoSymbol) 0 (NoSymbol) ) trace:keyboard:X11DRV_KeyEvent Adjusting NumLock state. trace:keyboard:KEYBOARD_GenerateMsg OFF + Keypress => generating DOWN and UP messages. trace:keyboard:KEYBOARD_GenerateMsg INTERM : don't treat release of toggle key. InputKeyStateTable[0x90] = 0x1 trace:keyboard:X11DRV_ToUnicode NumLockMask = 0010 trace:keyboard:X11DRV_ToUnicode AltGrMask = 2000 trace:keyboard:X11DRV_ToUnicode Found keycode 77 (0x4D) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0xff7f trace:keyboard:X11DRV_ToUnicode NumLockMask = 0010 trace:keyboard:X11DRV_ToUnicode AltGrMask = 2000 trace:keyboard:X11DRV_ToUnicode Found keycode 38 (0x26) trace:keyboard:X11DRV_ToUnicode NumLockMask = 0010 trace:keyboard:X11DRV_ToUnicode AltGrMask = 2000 trace:keyboard:X11DRV_ToUnicode Found keycode 45 (0x2D) trace:keyboard:X11DRV_ToUnicode NumLockMask = 0010 trace:keyboard:X11DRV_ToUnicode AltGrMask = 2000 trace:keyboard:X11DRV_ToUnicode Found keycode 30 (0x1E) trace:keyboard:X11DRV_ToUnicode NumLockMask = 0010 trace:keyboard:X11DRV_ToUnicode AltGrMask = 2000 trace:keyboard:X11DRV_ToUnicode Found keycode 32 (0x20) Characters do appear on screen, this time. Could it just be that edit control (I'm using notepad to test this) does not support UTF-8? Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Status Page Dll's --My Status :)
Gregory M. Turner wrote: So, maybe the percentage should, indeed, go higher, to 80% or what-have-you (I'd still like to finish split cabs, and build some tests, before we go bumping the completion percentage). It won't reach 100% until it's ready. That aside - this is an OpenSource project. You decide what your itch is. Visual Studio seems to statically link against cabinet.dll anyhow -- it's quite possible it wouldn't come up much at all -- maybe in WinZip or something. I doubt winzip is using any of MS's compression, but I may be wrong here. Check your assumptions against real life is my advice. Certainly the most urgent need for this implementation is to get various installers working, which AFAIK only requires decompression. Btw, there are some setupapi APIs which ought to be trivial to bang out once the FDI APIs are in place... I think they are all decompression-only, which would tend to strengthen the argument that the majority of the utility of the dll is in the decompression APIs. It appears that where work/result is concerned, decompression is the most important part. -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Status Page Dll's --My Status :)
Gregory M. Turner wrote:
But encoding is inherently harder to implement than
decoding (there's a lot more "to do", and usually no single right answer, so
you never know when you're done).
Ah?
Every book, software and piece of common knowledge tells me that
decoding is WAY more difficult. "Be restrictive in what you produce, and
permissive in what you accept" means that, when decoding, you need to
accept broken encodings too, as well as encodings that took a different
path than the one you would take (different algorithm, different
paramters, optional parameters, etc). When encoding, you need to select
a single path and go that way.
I own a nice book on compression, and I
could do this code, but also I would be implementing from scratch instead of
borrowing from others... so if these percents measure man-hours, we very well
might be at more like 15%!
I think there is no definite answer, but the general gist is that we
measure usability.
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Re: Bidi B4
Hi Alexander, Please let me know if my patch series was rejected, and if so, why. If your'e just not over the backlog yet, I appologize for the noise. Shachar Shachar Shemesh wrote: Apply against previous patches, using -p1 Changelog: Shachar Shemesh <[EMAIL PROTECTED]> * Fix compilation errors when ICU library is not available. -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: DEVENUM.DLL Implementation
Lionel Ulmer wrote:
Well, if you want to start work on Quartz, feel free to do it, you would be
our saviour (to all the gamerz out there who cannot have intro / cutscene
movies due to the missing Quartz stuff in Wine).
How do you get the game to run, then?
I have a game (Rubik's playground) that won't start because the start
movie can't load.
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Re: loading and running windows dlls in a linux program
Stefan Sperling wrote: Will this affect my whole app or can I tuck the winelib dependency away in a seperate module? Again, I bet there's a lot of documentation on that in the sheer amount of wine docs, is there? Stefan This will, in fact, affect your entire app. You can, however, create a stub utility. This stub will be the winelib. You should be able to use it from a regular ELF exec, and communicate with the PE DLL that way. Not sure what the implications be in your case, however. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Wineconf??
Keith Matthews wrote: On Thu, 5 Jun 2003 11:25:32 -0700 (PDT) hatky <[EMAIL PROTECTED]> wrote: I suggest we hold in Tel-Aviv. I'll organize the place. I am for it ;-) Hatky. No no no. The ultimate threat - Baghdad Baghdad is probably not as frightening as it used to be. I would have suggested Teheran (would be a great chance to visit FriBidi's maintainer), but this is only REALLY frightening to Israelies. I guess Havana would be a good place in that respect `-) Damn, we are running out of good conflict points in the world (either that, or everything is becoming equally unsafe). Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Wineconf??
Jeremy White wrote:
You've hit the nub of it. Someone needs to step up and organize it;
That's where I'm at a tough spot.
On the one hand I really want it to be somewhere that is reasonable for
me to get to. The US are DAMN expensive to travel to from where I am.
On the other hand, noone from France or Germany seems to be taking the
initiative.
Normally, I would take the initiative myself, only I'm afraid the places
I can organize wouldn't rank too much higher than Liberia. Leaving the
political discussion out of it, this would mean that the conference
would be meaningless. So all I am left with is pleading someone else to
take the initiative.
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Re: [FYI] Vacation
Dimitrie O. Paun wrote:
Folks,
I'm leaving for vacation today for a month, I'll be back July 7th.
I'll probably read my email from time to time, but I will not be
very active on the lists.
All the best, and I'll see you soon! (maybe Wineconf? :))
No way!! You cannot go on vacation before Alexander returns. The two of
you are 85% of the wine development force :-)
Oh well, let's just push 0.9 back another month...
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Re: loading and running windows dlls in a linux program
Stefan Sperling wrote: But I can see what functions are being called in the object code (thanks nm). Three of which come from wine: LoadLibraryA GetProcAddress FreeLibrary Hi Stefan. What you just saw is the bare minimum you need in order to load a library. I'm afraid, however, that it is far from all you need. First, when you load another library, that library may need any DLL at all. In order to assess how much of Wine you need, you need to also look at the DLLs loaded. Also, please bear in mind that GetProcAddress can load other functions, and those functions called. Are these all I need? Almost defenitely not. In theory, this looks about enough to be able to load a shared object... but I will need a lot of other wine internals too, in case a dll does a system call (like malloc, which will definitely happen), won't I? Yes. That can, potentially, grow to be the entire rest of Windows. Most likely, however, by looking at the DLLs loaded, you can narrow that down, somewhat. What happens if I pass a pointer to a method contained in a windows dll?? Will wine take care about low level stuff like keeping track of memory layouts of structs and convert them if they are incorrect? More precisely: If I reimplement data structures external to the dll but used by it, will the difference in memory layout between the original struct the dll expects and my new implementation under linux matter? Sometimes. The theory goes thus: An ELF binary can only call other ELF binaries. A PE (Windows) binary can only call other PE binaries. Wine invented something called "winelib executable". This is an ELF library that can also link to PE DLLs. It appears that your best bet, if you don't want to embark on massive copy/paste activity, is to create your util as a winelib. There are some disadvantges to that as well (a dependancy on Wine, for one). I'll let someone who's actually worked with winelib answer those parts, however. Thanks stefan Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Wineconf??
Dimitrie O. Paun wrote:
Actually, I think Toronto is a good place. It has a big airport,
(which means most people can get direct flights) it is kinda in
the middle between West coast and Europe, it is cheap, clean, safe,
and fun. You get to see the CN Tower, and Niagara falls is only 1.5h
away. If you like to eat, there are excellent restaurants for any
cuisine imaginable, which is always nice.
The weather is not great in the winter, but falls are absolutely
gorgeous (but short :)). We get nice weather in Sep, even Oct though.
Something to consider...
Where's the fun in taking everything we say seriously?
I think Europe is the best compromise for people on most parts of the
world. It has direct flights from almost everywhere (are there any New
Zeland/Australia/Antartica Wine developers? I'm also not sure about
South America).
On a side note - I'm not sure I will be able to afford a conference in
the Americas.
The thing I was trying to say, however, is that with August approaching,
if we want a conference around that time, someone had better start
organizing it. I don't mind being that someone, but then you will get a
conference in Tel Aviv. Personally, I think most Wine members should be
more worried about the weather in Tel Aviv in August than about anything
else (hot and humid. Not New York grade bad, but not very far either),
but somehow I (sadly) suspect not many will arrive anyways. As such,
maybe it's best if someone else organized it.
If people are REALLY worried about Tel Aviv, I can offer Jerusalem,
where it isn't so humid (plus the city itself is beutiful, and you are
only an 1.5h drive away from all those wonderful places you got to hear
about in the news).
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Re: Wineconf??
Jeremy White wrote: There has been no decision on it. My threat to hold it in Minnesota in January was not sufficiently intimidating, apparently . I think I give a better threat, then. I suggest we hold in Tel-Aviv. I'll organize the place. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Wineconf??
Hi,
So, what was the decision regarding wineconf? Are we going to have it?
Where? When?
I'm trying to organize a local Linux conference (called "August Penguin"
- try to guess which month that's going to be in. No no, guess). It
would be really embarresing if, in the end, I won't be able to atend
either conferences.
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Re: Add root drive mapping to default config file
Mike Hearn wrote: Because mapping '/' by default is plain ugly in my opinion... It's like shipping some server application with a default blank password :-) Can't agree, I'm not seeing the security problem here. Unless you subscribe to the belief that too many Win32 programs have spyware that would be interested in gigs of ELF binaries and config files (as they would be able to see drives/network mappings under windows anyway), I don't see what harm it could do. Just wanted to go on record backing Lionel. I am against mapping the root of the drive to Wine. There have been cases in the past (even published on Slashdot), when people using Wine were infected with document sending viruses. In that case, the root mapping meant things got out. Mapping the root is a bad security decision, even if we don't see the exact attack vector at the moment. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Bidi B2 - GetCharacterPlacement order array
Dimitrie O. Paun wrote:
On Mon, 2 Jun 2003, Shachar Shemesh wrote:
Seems like it's not my day for URLs.
http://shemesh.biz/lecures.html
^t^
No, it really isn't :P
http://shemesh.biz/lectures.html
I told you it's not my URLs day.
I'll go to sleep now, if you don't mind.
Sh.
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Re: Bidi B2 - GetCharacterPlacement order array
Shachar Shemesh wrote:
David Laight wrote:
Be aware that strncyp() rarely DTRT, in particular:
- it doesn't guarantee to zero terminate the target
- it is required to zero fill the target buffer
Neither of these is usually desirable.
Well aware of both. Thanks. I'm routinely giving lectures about them
(http://shemesh.biz/lectures).
Seems like it's not my day for URLs.
http://shemesh.biz/lecures.html
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Re: Bidi B2 - GetCharacterPlacement order array
David Laight wrote:
Be aware that strncyp() rarely DTRT, in particular:
- it doesn't guarantee to zero terminate the target
- it is required to zero fill the target buffer
Neither of these is usually desirable.
Well aware of both. Thanks. I'm routinely giving lectures about them
(http://shemesh.biz/lectures).
Since the buffer is not zero terminated to begin with, 1 is not a
problem. Since the loop that strncpy replaces copied n bytes over from
the old buffer to the new one, neither is 2. This does impose the
theoretical problem that if the original string WAS zero terminated, and
the NULL was not the last WCHAR in the buffer, we change the semantics.
I doubt very much, however, that you will find a program that relies on
this. I don't even know what Windows does under the same circumstances.
Many systems have a strlcpy() function which does what you want much
more often.
Well aware of that too. strncpy is really the most fitting here. Trust me.
OTOH is the target buffer can be too short with valid data, they you
need to (typically) dynamically allocate a buffer.
Not applicable to GetCharacterPlacement.
David
Thanks.
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Re: Wine packages
puoti wrote: Hi, I've read the wwn n° 171, I'm the one that builds the sourceforge wine packages for Mandrake, I just want to ask if you can please let me know when you add bidi support to wine, what headers I must install, and if I have to add any explicit options to configure, so I can build wine rpms with bidi support, best regards, Ivan. Hi Ivan, First, I'm forwarding your email to the list. I hope you don't mind. I think other people may find it useful. I have to say that these weekly news are doing their job great! I have already sent in the patches. They were not included, mostly because Alexander is away. When they are included, you will need any fairly recent ICU installed locally on your machine. You can get the sources for the library at http://oss.ibm.com/icu/. I would go for their latest released version (2.5), rather than the beta. Unfortunetly (and this has been a major consideration against using it, but other factors were stronger), ICU has no packages for platforms other than Debian. You don't have to give configure any explicit option (well, assuming Alexander doesn't change anything, that is). Notice that you actually need to compile ICU, however. Merely adding the headers is not enough, as it is STATICALLY linked to gdi. On the bright side, this doesn't add any difficult dependancies to wine. Hope this helps, Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Resources page updates........
Tom wrote:
Hello,
I was looking over the Resource page :
http://www.winehq.com/?page=resources
And ive found we are linked to some ... not alot but a couple 404's
For example under "WIN 32" _Win 32 API Intro_ .. We have :
http://msdn.microsoft.com/library/en-us/win32/win32start_1xyd.asp
and it is one of the 404 sites.. I would like to change this to :
http://www.winprog.org/tutorial/
So the question is ???
On all the 404's if I find a equivalent to what we now have is
it alright with everyone
if I send a patch to fix this ? ( I would only guess yes )
Ive also found some sites that have the same info that were pointing
to.. And there more upto
date than the ones that we currently point to. I would like to also
update there links as well.
I'm just asking here for thoughts/insight ..
If there are no objections ill work on this patch monday.. lots of
lead time right :)
Tom
Hi Tom,
Your'e going about it the wrong way. From my experience, it usually take
the same time to ask about things and to actually do them. Next time, do
the later. If anyone objects (and yes, some people actually read those
patches you send), they will let you know.
This is a free software project. The vote always goes with the people
who send the diffs.
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Re: Bidi B3 - GetCharacterPlacement final cleanups
Andreas Mohr wrote:
Hi,
On Sat, May 31, 2003 at 06:49:57PM +0300, Shachar Shemesh wrote:
Apply with -p1
Changelog:
Shachar Shemesh <[EMAIL PROTECTED]>
* Removed all redundant "GetCharacterPlacement" code from the
internal reordering function. WINE_BiDi_reorder now does only that.
* Removed all reordering code from "GetCharacterPlacementW". It now
has only the non-reordering stuff, calling "WINE_BiDi_reorder" for
the reordering code.
Nice ChangeLog!
And... what am I supposed to apply with -p1 here? Your mail or what? :)
Andreas Mohr
I just wrote the changelog, isn't it clear what the actual patch should be?
Ok, so for all those of you with no imagination, here is the actual
patch. Happy?? Hah??
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
diff -u -r -x '*.o' -x CVS wine.ref/dlls/gdi/bidi.c wine/dlls/gdi/bidi.c
--- wine.ref/dlls/gdi/bidi.c2003-05-31 12:49:58.0 +0300
+++ wine/dlls/gdi/bidi.c2003-05-31 15:52:20.0 +0300
@@ -48,56 +48,20 @@
return BidiAvail;
}
-DWORD Wine_GCPW(HDC hdc,/* [in] Device context for which the rendering is to
be done */
+BOOL Wine_BiDi_reorder(
LPCWSTR lpString, /* [in] The string for which information is
to be returned */
-INT uCount, /* [in] Number of WORDS in string. */
-INT nMaxExtent, /* [in] Maximum extent the string is to take (in HDC
logical units) */
-GCP_RESULTSW * lpResults, /* [in/out] A pointer to a
GCP_RESULTSW struct */
-DWORD dwFlags, /* [in] Flags specifying how to process the string */
-DWORD dwWineGCP_Flags /* [in] Wine internal flags - Force
paragraph direction */
+INT uCount, /* [in] Number of WCHARs in string. */
+DWORD dwFlags, /* [in] GetCharacterPlacement compatible flags
specifying how to process the string */
+DWORD dwWineGCP_Flags, /* [in] Wine internal flags - Force
paragraph direction */
+LPWSTR lpOutString, /* [out] Reordered string */
+INT uCountOut, /* [in] Size of output buffer */
+UINT *lpOrder /* [out] Logical -> Visual order map */
)
{
-DWORD ret = 0;
-SIZE size;
-UINT i, nSet;
-
-TRACE("%s, %d, %d, 0x%08lx\n",
- debugstr_wn(lpString, uCount), uCount, nMaxExtent, dwFlags);
-
-TRACE
-("lStructSize=%ld, lpOutString=%p, lpOrder=%p, lpDx=%p, lpCaretPos=%p\n"
- "lpClass=%p, lpGlyphs=%p, nGlyphs=%u, nMaxFit=%d\n",
- lpResults->lStructSize, lpResults->lpOutString,
- lpResults->lpOrder, lpResults->lpDx, lpResults->lpCaretPos,
- lpResults->lpClass, lpResults->lpGlyphs, lpResults->nGlyphs,
- lpResults->nMaxFit);
-
-if (dwFlags & (~GCP_REORDER))
-FIXME("flags 0x%08lx ignored\n", dwFlags);
-if (lpResults->lpCaretPos)
-FIXME("caret positions not implemented\n");
-if (lpResults->lpClass)
-FIXME("classes not implemented\n");
-
-nSet = (UINT) uCount;
-if (nSet > lpResults->nGlyphs)
-nSet = lpResults->nGlyphs;
-
-/* return number of initialized fields */
-lpResults->nGlyphs = nSet;
-
-if (dwFlags == 0) {
-/* Treat the case where no special handling was requested in a fastpath way */
-/* copy will do if the GCP_REORDER flag is not set */
-if (lpResults->lpOutString)
-for (i = 0; i < nSet && lpString[i] != 0; ++i)
-lpResults->lpOutString[i] = lpString[i];
-
-if (lpResults->lpOrder) {
-for (i = 0; i < nSet; i++)
-lpResults->lpOrder[i] = i;
-}
-}
+TRACE("%s, %d, 0x%08lx\n",
+ debugstr_wn(lpString, uCount), uCount, dwFlags);
+
+TRACE("lpOutString=%p, lpOrder=%p", lpOutString, lpOrder );
if ((dwFlags & GCP_REORDER) != 0) {
UBiDi *bidi;
@@ -108,7 +72,7 @@
if( bidi==NULL ) {
WARN("Failed to allocate structure\n");
SetLastError(ERROR_NOT_ENOUGH_MEMORY);
-return 0;
+return FALSE;
}
switch( dwWineGCP_Flags&WINE_GCPW_DIR_MASK )
@@ -128,13 +92,13 @@
}
ubidi_setPara( bidi, lpString, uCount, level, NULL, &err );
-if( lpResults->lpOutString!=NULL ) {
-ubidi_writeReordered( bidi, lpResults->lpOutString, uCount,
+if( lpOutString!=NULL ) {
+ubidi_writeReordered( bidi, lpOutString, uCount,
(dwFlags&GCP_SYMSWAPOFF)?0:UBIDI_DO_MIRRORING, &err );
}
-if( lpResults->lpOrder!=NULL ) {
-ubidi_getLogical
Re: Bidi B2 - GetCharacterPlacement order array
Dimitrie O. Paun wrote: On May 31, 2003 05:45 am, Shachar Shemesh wrote: +/* Treat the case where no special handling was requested in a fastpath way */ +/* copy will do if the GCP_REORDER flag is not set */ +if (lpResults->lpOutString) +for (i = 0; i < nSet && lpString[i] != 0; ++i) +lpResults->lpOutString[i] = lpString[i]; What about a strncpy here: +if (lpResults->lpOutString) +strncpyW(lpResults->lpOutString, lpString, nSet); Probably a good idea. These lines predate my involvment in Wine, so I did not touch them under the "it works" discipline. I copied them over from objects/font.c (GetCharacterPlacementW), and I'm sending out another cleanup patch that removes these lines. I'll fix the upstream copy, if you think it's woth it (I am touching that function anyways). Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Generating incremental diffs
Johan Dahlin wrote:
I tried running "diff -u -r wine.ref wine". The problem is that this
generated tons of diffs in files in the "CVS" directory. Don't ask me
why there were differences there.
This is the right way, you just have to tweak the arguments to diff or
grep away some stuff (CVS for example).
Use -x or -X options combined with grep [-v]
-x PAT --exclude=PAT Exclude files that match PAT.
-X FILE --exclude-from=FILE Exclude files that match any pattern in FILE
Thanks! I must have misread the documentation. Programing at half past 1
AM is not as effective as it might be.
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Generating incremental diffs
I need to generate diffs between my previous patch and the current one. Unsuprisingly (as Alexander is on vacation), the previous patch was not applied. When diffing against CVS, I usually just do "cvs diff -u". In this case, I have checked out a new tree from CVS, applied the old diff on that tree (so I have a tree that is the way CVS would look if my previous patch was applied). Now what? I tried running "diff -u -r wine.ref wine". The problem is that this generated tons of diffs in files in the "CVS" directory. Don't ask me why there were differences there. Any other ideas? I know other people have done this before... Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Wine folks interested in a CHM spec?
Mike Hearn wrote: Anyway, as to maintainership, this is a good question. But how comes adding a clone of IE is nuts, but the rest of Wine is sane, hmm? :) This whole thing is completely crazy to some extent, but here we are in 2003 with two companies working on Wine and many volunteers it would probably require a D3D style dedicated team to work on it though, which so far doesn't exist. Oh no - you open software developers are off your head! Next thing you will be developing a .NET replacement! Wait, you are. Hmm, nobody will be crazy enough to work on an entire GUI shell, though. Two you said? Not including the small ones? Not a modern OS, though. HOW many? Surely none is enterprise ready! What precentage of web servers? PEOPLE! GET A LIFE Good thing I'm not part of it. What do you mean by "grep wine/AUTHORS"? AARGH P.S. Yes, I spent the day working on a perl util to convert an MSSQL DB to postgres for a client (yes, I'm getting paid to do this, at least, I hope does anybody happen to know something that does that already?). I think expecting any USEFUL mails from me would be a total waste of time. Sorry for the OT posts. -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Wine folks interested in a CHM spec?
Mike Hearn wrote:
Unfortunately, it seems KWQ is mostly MacOS specific. It's written in
Objective C++, a language I didn't even suspect the existance of until I
read the sources. Example:
...
As if C++ wasn't hard enough to read already!
On a 100% unrelated note, and since this list does not have LKML's
faschist charter, I'll go really OT and mention that Objective-C was
developed parallel to C++, so any attempts to claim that it was
redundant are a little hind-site oriented. Major IIRC disclaimer here,
of course.
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Re: little WWN problem
Dimitrie O. Paun wrote: Hi folks, How come "The top 5 posters of the week" are almost always screwed up: 1. 28 posts in 68K by Alexandre Julliard 2. 35 posts in 89K by Dimitrie O. Paun 3. 18 posts in 41K by Gerhard W. Gruber 4. 11 posts in 91K by Mike Hearn 5. 1 posts in 3K by Shachar Shemesh What? Don't you think a single post should award me top poster?? You don't like me any more??? Nobody likes me any more Nobody ever liked me! I now return you to your usual boadcast. -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Building documentation start
Francois Gouget wrote: On Tue, 27 May 2003, Shachar Shemesh wrote: This includes the begining of a Build doc in wine-devel. It also contains a list of the soft-dependancies I spotted, and urging the packagers to consider this list. This section does not belong in the Winelib guide. The Winelib guide deals with how to compile Windows applications using Wine, not how to compile Wine itself. Phew! Good thing I placed it in wine-devel, then :-) This list of dependencies would fit better in the PACKAGING guide, between the REQUIREMENTS and WINE COMPONENTS sections. I know. I'm thinking of just placing a comment there that directs packagers to the wine-*devel* docs. You could also add something like this to the REQUIREMENTS section: * A build system satisfying all Wine's soft and hard dependencies so that the resulting Wine package has all Wine's features. I'm not sure about the hard dependancies. I don't feel comfertable recommending to packagers to depend on hard dependancies, as that changes what is ultimatly needed to install the package. I think hard dependancies are up to the packager to decide whether she wants them in or not. Soft dependancies, on the other hand, have very little, if any, reason to be excluded. You may also want to point to this section from the README's 'COMPILATION' section. Could be a good idea, yes. -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: REMOVE ME
Javier López wrote: Hello, please wanted that they removed me of his list of post office, since he is something very disagreeable, arrive approximately 20 to me at 30 daily e-mail and no longer I support it, my square is fulled. Please Remove ME OF ITS LIST! Hi Javier, In order to be removed, please send an email to [EMAIL PROTECTED] with a subject of "unsubscribe", and follow the instructions from there. Everyone else - I think it's time to update the counters on the web site. They are horribly out of date. Wine has experienced a wonderful expansion over the past year, but this means that we can no longer claim that wine-devel is 25 msg/day (more like 35msg/day on my unofficial counting), nor wine-patches 8msg/day (more like 20msg/day). This growth is really impressive, but we really need to update the counters accordingly. Shachar P.S. I have been walking around with the feeling that wine is reaching it's growth flex point (where development suddenly accelerates) for quite some time. Comparing the numbers claimed on wine-patches to the real numbers shows over 100% of growth in the amounts of fixes people send in. This shows that we are finally heading torwards the so desired beta stage. -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Error in CVS
Try running "cvs up -Pd". A directory recently added to CVS did not make it into your directory structure, which generally means that you have not asked for new directories (-d option). Shachar Vilppa Salt wrote: When running ./configure with latest cvs Wine: config.status: creating dlls/ctl3d/Makefile config.status: creating dlls/d3d8/Makefile config.status: creating dlls/d3dim/Makefile config.status: creating dlls/d3dx8/Makefile config.status: creating dlls/dciman32/Makefile config.status: creating dlls/ddraw/Makefile config.status: creating dlls/devenum/Makefile config.status: creating dlls/dinput/Makefile config.status: creating dlls/dinput8/Makefile config.status: creating dlls/dmusic/Makefile config.status: error: cannot find input file: dlls/dmusic/Makefile.in --- Vilppa- Sunpoint.net ilmoittaa: Sunpoint.net tarjoaa kaikille rekisteröityneille käyttäjilleen kuukausimaksuttoman Internet -yhteyden (pvm). http://www.sunpoint.net/SunAds/click.htm?mode=footer&id=71&jump=http%3A%2F%2Fwww.sunpoint.net -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: wine server and services ...
I guess you can blame the war for some of the delay with that (I live about where Saddam has aimed most of his scuds 12 years ago - I was more into launch probabilities and trying on gas masks than wineboot lately). It basically boils down to this - wineserver has not started any synchronous wine utils in the past (the font generation is performed, as far as I can tell, in the server context itself), and the whole thing is taking time and patience to sort out. If all you want is asynchronous services starting, that's easy (I practically have the code lying around somewhere). If you want services to start halting other processes before they start - that's going to be tricker. In any case, you can merge that right into wineboot itself. It currently has several command line options that control how it starts. One of the option is to do a full session startup, and another is to do just the pre-login startups (that one doesn't have a command line yet, but that's really simple). We can put services support there. We can, but I don't recommend it. I think we should aim for Wine to have a simple RPM/Deb install. There are several implications to this simple statement. One of them is using a shared (unix) system wide directory structure (be it on a real or on a fake windows, doesn't really matter. Personally I think fake windows is the only thing that really matters). This, in turn, means that services should be started on system wide basis. Services also have a different set of permissions and users than the usual processes. In short - I think they belong in neither wrapper nor wineboot, but require a more specific solution. Shachar Sylvain Petreolle wrote: dont do it ! even wineboot isnt started by the server ! You might want to make a wrapper application like wine/programs/services. This program could then be started by wineserver and a config option if you want to try and run a NT service. I dont really see the point on running services under WINE unless you want to try and install AV software that loads as a service =) -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: 'make depend' b0rken on fresh check-out
Keith Matthews wrote:
?? I've just done a checkout and tools/wineinstall is working fine (not finished yet, compiling ole stuff).
wineinstall tries to do "make", and only if it fails it does "make
depend". This probably means that by the time make depend runs, make has
already built libs/port.
This does not mean that everything is ok.
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
CVS doesn't compile from clean
Hi, When trying to run make depend on a clean CVS build, I get errors trying to link the tools folder. Manually running make in libs/port solves this problem. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: wine and services ..
I think that http://www.winehq.com/hypermail/wine-devel/2002/10/0578.html will give you most of the answers you are looking for. Shachar Lars Segerlund wrote: I have asked a before about NT services, and about the support for them in wine, does wine have any support for NT services ? I'm getting errors on some code which I have written for NT and it runs on NT 2k xp , and it seem's that there is no support for services. If I wanted to get started on an implementation, how difficult and where would I look ? It seem's that wined should be able to handle stuff like this ? / regards, Lars Segerlund. -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: W->A dlls/commdlg/fontdlg.c
Tony Lambregts wrote: Well don't feel too bad but I have no intention of working on this at this time. I have started to write code. MAY have a fix soon. What I might suggest is that we start a bug report in bugzilla for this that Dimi can link to. http://bugs.winehq.org/show_bug.cgi?id=959 is slightly related. I have an interview on Tuesday. Hopefully it will turn into a (paying) job and if that is the case I will have less time to spend on wine than I currently do. Good luck. Let's not forget that there are other important things in life. Myself, I am also at a time of lower Wine availability. This is mainly due to trying to establish an NPO for handling Free and Open source software in Israel (wer'e calling it "Hamakor", which stands for both "Source" and "beak"). Unfortunetly, one OSS activity do tend to come at the expense of another. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: W->A dlls/commdlg/fontdlg.c
Tony Lambregts wrote:
I would appreciate Any comments about this.
I have started to work on setting fontdlg straight. The main obsticle is
(besides the fact that I don't have time to look at it) is that
ChooseFontA and ChooseFontW behave slightly different on Windows.
On Windows, ChooseFontA be default displays a charset selection
combobox. When selecting a font that has several charsets, the selection
has the full list of the charsets. The "Sample" area shows (W2K) "AaBb",
followed by several letters that are charset dependant ("YyZz" for
western). The sample text code is, actually, already implemented and
commited (the actual sample text is only there for Western and Hebrew,
because that's all I had, but it's a simple matter of placing text in
the "SAMPLE_LANG_TEXT" for more languages).
Calling ChooseFontW, on the other hand, displays the charset selection
(most amuzing), but it is disabled (makes no sense for Unicode). When a
font is selected, the sample text for ALL charsets in that font is
displayed.
Wine's fontdlg is currently not in a very good shape. When a font has
several charsets, the font appears several times in the font dialog.
Selecting a given instance of the font dictates which charset you will
receive. Of course, at the moment, unless the charset has a unique
sample text, you have no way of knowing which charset that was that you
have selected.
All of these problems are not very difficult to solve, but they require
some time. The common dialog itself needs to be a unicode dialog
accepting a boolean dictating whether charset selection is necessary. It
then needs to call "EnumFontFamiliesExW" instead of "EnumFontFamiliesA".
This MAY also indicate a bug in "EnumFontFamilies". I'm not sure whether
it was supposed to return once for each font, or whether it should
really return each charset of each font as a different entity.
Part of the reason all of this is taking me time, besides the fact that
I don't get around to Wine very much of late, and the fact that, when I
do, I'm working on making wineboot autowork, is that the entire font
dialog experience is jittery. It effectively resets the size and face
every time a new font is selected, which is not the desired effect.
Fixing this requires a bit more work. This comes hand in hand with the
fact that, when initializing it from an existing structure, the
structure's existing info is not reflected in the dialog.
Hope this was not too technical an answer to your question. If you feel
like working on it, please let me know. It will allow me to work on
wineboot with much clearer concious.
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Re: running wineboot from the server - HELP!
Alexandre Julliard wrote:
Shachar Shemesh <[EMAIL PROTECTED]> writes:
Can someone who understands the server, and the interaction between
the server and normal apps comment on this scheme?
Also, how do I at all make each and every prog load wineboot.dll?
IMO you are on the wrong track here. We definitely do not want to do
boot processing every time an app starts, our startup times are
already pathetic enough. There are three cases where boot processing
should happen:
1) When an app reboots the system with ExitWindows
2) When the user explicitly requests it
3) At login time when starting the Unix desktop
2) and 3) are external to Wine, and are the responsibility of the user
and/or the packager to make sure the proper scripts are modified. So
this leaves 1) which is basically a CreateProcess("wineboot") at the
end of ExitWindows.
I am working on different command line options for the different
scenarios. I'm having some difficulties with what to do with 2 (I know
what 1 and 3 should do).
I don't think we need to worry much about delaying other apps either;
in case 2) we may want to display a message when everything is done,
but otherwise I wouldn't worry about it.
The synchronization problem is only related to the pending rename
option. This is guarenteed handled by Windows before any Win32 process
starts. As such, it may (and is actually quite likely) to have a
post-boot process depend on the renames being complete before it can
work. Anything that is run from wineboot itself is handled, but I'm
worried about external utils.
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
running wineboot from the server - HELP!
Hi, I know I promised this over three weeks ago, but things have been very busy for me lately. This email is slightly long. Please please please read through it. I need help to get wineboot working automatically (a blocking issue for 0.9), and I need someone who understands both the server and the loading order to comment. This is the first part of the required change. Applying it at the moment does not make sense, as I am not yet sure that this is the right one (it may make more sense to point the env at the .exe.so file rather than the wrapper - more about that in a second). I am, more or less, ready to give up. Someone suggested I look at the way caching the font metrics delays normal load. Well, I tried. I'm not sure I got it right, though. If I understand correctly, the way to go for wineboot to run is this: wineboot, upon first run, will aquire a system wide named mutex that means "I am working on it". If the mutex exists, it will block on it. Once it got it it will immediatly release it and exit. If the mutext doesn't exist at all, it will aquire it and do it's magic. Once done it will release it, but not delete it, and exit. All that is left to do is that all programs must load wineboot as part of the startup. It may require modifying it to be a DLL instead of an EXE, but so be it. Can someone who understands the server, and the interaction between the server and normal apps comment on this scheme? Also, how do I at all make each and every prog load wineboot.dll? Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/ Index: programs/winelauncher.in === RCS file: /home/sun/sources/cvs/wine/programs/winelauncher.in,v retrieving revision 1.2 diff -u -r1.2 winelauncher.in --- programs/winelauncher.in5 Jul 2002 21:18:41 - 1.2 +++ programs/winelauncher.in10 Mar 2003 21:27:27 - @@ -37,6 +37,7 @@ [EMAIL PROTECTED]@ [EMAIL PROTECTED]@ WINESERVER= +WINEBOOT= [EMAIL PROTECTED]@ #-- @@ -178,12 +179,20 @@ WINESERVER=$WINEBIN/wineserver fi +if [ -x $WINEBIN/wineboot ] ; then +WINEBOOT=$WINEBIN/wineboot +fi + #-- # Hey, if we built Wine from source, let's add a little extra fun to # mix it up a bit #-- if [ -x $WINEBIN/server/wineserver ] ; then WINESERVER=$WINEBIN/server/wineserver +fi + +if [ -x $WINEBIN/programs/wineboot/wineboot ] ; then +WINEBOOT=$WINEBIN/programs/wineboot/wineboot fi if [ -r $WINELIB/dlls/ntdll.dll.so ] ; then Index: tools/winewrapper === RCS file: /home/sun/sources/cvs/wine/tools/winewrapper,v retrieving revision 1.3 diff -u -r1.3 winewrapper --- tools/winewrapper 25 Sep 2002 03:29:56 - 1.3 +++ tools/winewrapper 23 Feb 2003 13:49:11 - @@ -70,8 +70,9 @@ fi WINEDLLPATH="$topdir/dlls:$topdir/programs" WINESERVER="$topdir/server/wineserver" +WINEBOOT="$topdir/programs/wineboot/wineboot" WINELOADER="$topdir/miscemu/wine" -export LD_LIBRARY_PATH WINEDLLPATH WINESERVER WINELOADER +export LD_LIBRARY_PATH WINEDLLPATH WINESERVER WINEBOOT WINELOADER # any local settings ? if [ -f "$topdir/.winewrapper" ]
OT: xeyes for windows
Hi, sorry for the off topic. The "XEyes for windows" I have written has generated some traffic on my web site, with totally made up URLs. As I do wish to release it as GPL, and as this is the only place I have every announced it's existance, I am giving the correct URL to the package. The package can be downloaded from http://www.shemesh.biz/code.html Enjoy, Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: New conformance test for user32.dll
Alexandre Julliard wrote:
Not sure where that documentation is, but it's much better to diff new
files than to add separate attachments. The basic rules are: no
attachments, no mime crap, no line wrapping, a single patch per
mail. Basically if I can't do "cat raw_mail | patch -p0" it's in the
wrong format. I'd guess that at most 20% of the submitted patches
follow the rules :-(
I usually attach the diff, but make sure that the mime type allows it to
be displayed. I received no complaints so far from Alexander, but now
I'm not sure why.
The eventual mail has Mime crap, but as it is not encoded Alexander
should be able to do cat | patch. This also guarantees that there will
be no line wraps.
I belive this to be the best way, but people are so much against it that
I have kept my mouth shut so far in these discussions. (it's not as if I
submit too many patches lately :-( )
Shachar
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Re: Wine 0.9 config applets?
Sylvain Petreolle wrote: Of course I gain some security. Some spyware are launched by the Run entries to be difficult to remove by normal users. Virii are launched as services to gain security privileges, or, easier to program, a simple program launched by the Run entries can delete random file(s) at startup. Wouldn't it then be better to just write a cpl that manages the automatic startup programs? We can even port it to Windows and call it a "Project Wine spinoff" :-) Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Wine 0.9 config applets?
Sylvain Petreolle wrote: --- Shachar Shemesh <[EMAIL PROTECTED]> a écrit : > I don't think Viruses are a major issue. The way I see it, there are currently several functions wineboot fulfils, and we need to consider all of them: 1. Boot time operations - renaming pending files (wininit.ini and the pendingrename registry key) 2. Startup operations - runservices and runservicesonce and such. 3. Session startup: 1. Install related operations - RunOnce 2. Permenant operations - Run, startup folder etc. 3.2 is managed too by wineboot - for run only at the moment. Right you are. There is one solution for that : delay program starting like the font metrics cache generation does. Thanks. I'll look into it. (the problem with running it on startup is the race condition between the renames and the program starting). I think I have a solution to that problem, in the form of command parameters, but I'll be smarter when things progress. Like I said, it can be enabled by default. You don't gain any security from that, but it doesn't cost much either. -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Wine 0.9 config applets?
I don't think Viruses are a major issue. The way I see it, there are
currently several functions wineboot fulfils, and we need to consider
all of them:
1. Boot time operations - renaming pending files (wininit.ini and the
pendingrename registry key)
2. Startup operations - runservices and runservicesonce and such.
3. Session startup:
1. Install related operations - RunOnce
2. Permenant operations - Run, startup folder etc.
Wineboot currently focuses on 1, 2 and 3.1. This gives me the ability to
consider running it on wineserver *shutdown* (and when Alexander
suggested it, it sounded crazy to me, how times change). If we implement
the startup related activities as well, that will not be an option. (the
problem with running it on startup is the race condition between the
renames and the program starting). I think I have a solution to that
problem, in the form of command parameters, but I'll be smarter when
things progress.
As for the virus problem - while I guess I can disable startup, I'm not
sure it's the right idea. We are attempting to immitate the genuine
Windows environment, and that means, among other things, startups. The
more we progress, the more habitable our environment is going to be to
viruses and malwares. I don't think there is much we can do about it.
The user, on the other hand, would like to have a conveiniant
environment. Having many switches and tweaks will not improve their
ability to control Wine, quite the contrary.
Shachar
Sylvain Petreolle wrote:
In this case make sure we can desactivate it.
I dont want to see a plug-in/virus/popup generator/something else
loading itself automatically
Well wineboot needs to be automatically run, either at startup or
shutdown or whatever. Other than that, yep, it's all making good
progress it seems.
I'll try to get that in sometimes during this coming week.
Shachar
--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/
Re: Wine 0.9 config applets?
Mike Hearn wrote: Well wineboot needs to be automatically run, either at startup or shutdown or whatever. Other than that, yep, it's all making good progress it seems. I'll try to get that in sometimes during this coming week. Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: Incorrect locale selected
J. Grant wrote: Which means that my input method can be in japanese, but that all programs are in english. However, some programs (wine notepad and some installers etc) have some of the text in Japanese. Wine notepad has the "open file" dialog in Japanese, but the menus are in english. I am using Wine 20030115. Is this a known issue? Yes and no. In Wine everything is selected at one place, and is the equivalent of the "system default locale". Be warned, btw, that some things don't work very well with input when using UTF-8. Is it fixable? Probably. You need to get the concept of a user locale. Grab the system locale from LC_CTYPE and the user locale from LANG. Select resources based on the user locale. That would probably fix this issue. Havn't had the time (http://www.advogato.org/person/sun/#1) to actually go ahead and do it. Regards JG -- Shachar Shemesh Open Source integration consultant http://www.shemesh.biz/
Re: The richedit scrollbars
Duane Clark wrote: The easy fix is to have WM_NCCALCSIZE return the true size of the enclosing window, which is what we have done here. The more difficult fix is to create a custom Richedit MoveWindow procedure for use in the WM_SIZE message above. Since it is very unlikely that an app would call and use the WM_NCCALCSIZE message, we stick with the easy fix for now. Sorry for being a pest about this, and it's not like the Richedit is in my focus at the moment, but what does Windows do under the same circumstances? Changelog: A fix to get edit control scrolls bars to draw in the correct position. -- Shachar Shemesh Open Source integration consultant http://www.consumer.org.il/sun/
Re: Non-applied patches
Alexandre Julliard wrote: Shachar Shemesh <[EMAIL PROTECTED]> writes: I am referring to: http://www.winehq.com/hypermail/wine-patches/2003/01/0399.html This one should be applied soon. Great! That's the important one. I'm hoping to get to the point we have a charset selecting font dialog (and eliminate the W->A call while wer'e at it). and http://www.winehq.com/hypermail/wine-patches/2003/01/0401.html As you said yourself: "this is not a good patch". It's not fixing the problem just hiding it. Yes. It was a two minute hack, because I happened across the problem. -- Shachar Shemesh Open Source integration consultant http://www.consumer.org.il/sun/
Non-applied patches
Hi Alexandre, I'm just trying to understand whether you are still trying to fight the backlog, my patches fell through the cracks, or that you decided not to apply them. I am referring to: http://www.winehq.com/hypermail/wine-patches/2003/01/0399.html and http://www.winehq.com/hypermail/wine-patches/2003/01/0401.html If the last option, please explain what is wrong with them. Sh. P.S. A simple mail saying "I'm still fighting the backlog, I'll let you know when I've covered all the submitted patches" will suffice, as far as I'm concerned. -- Shachar Shemesh Open Source integration consultant http://www.consumer.org.il/sun/
Where oh where has Alexander gone?
Hi, The last commit to wine has been done almost two weeks ago. I understood from half an email that Dimi wrote that Alexander was away from the Internet (away for almost two weeks! *shudder*). Anyone knows where, when and what? Is all ok? -- Shachar Shemesh Open Source integration consultant http://www.consumer.org.il/sun/
Re: Windows API (What I have so far)
In our continous effort to to avoid understanding what the other one is writing by sending our own stuff, here is a version of my parser that does the actual generation of a HTML table. Also attached is this program's output when run against Dave's original HTML. The HTML is compressed with bzip, as when compressed with gzip it was over this list's quota (44Kb). Be warned that the file size after uncompress is 2.7MB(!!!), and it poses quite a problem for Mozilla to display (though it manages to, eventually). Also not that the resulting display is as ugly as an airport. This was, in fact, on purpose. If you view the source of the HTML, you will find that it was meant to be styled with a CSS, and thus contain no formating directives, but do contain "class" directives. Unfortunetly, my web design skills are close to nada, and so I do not consider myself up to the task of creating such a style sheet. If anyone else present would like to generate CSS for this table, please keep in mind that Table Data cells of class "CyclicDepend" are cells that, if marked, indicate that the DLL has a cyclic dependancy. It is therefor probably a good idea to give them a different background. Last, this program still has a bug, though I don't know how serious. When run it issues lots of warnings about use of uninitialized var. I believe this has the potential of indicating a real bug in the program, but the DLLs I have sample checked against the original input proved to be ok. Share and enjoy. Shachar Dave wrote: Ok, here is new HTML. I used c:\windows as the path so gdiplus would be included. I'll add the newlines, but haven't yet. So new HTML doesn't have them. At 12:25 AM 2/10/2003 +0200, you wrote: David Miller wrote: I checked my system for gdiplus.dll. It simply is not under c:\windows\system32, which is the path I gave when I made the sample HTML. It is under c:\windows\winsxs. The new program strips the path and dll extension in the HTML output. Would it be better to reverse that change, and include the path and extension to be compatible with your parser? I don't think that would be necessary. Just make sure that in the HTML you add a real NL after each (or otherwise make the interesting parts at most one per line), and that SHOULD work. My parser removed the path if it's there, and removes the extension if it's .dll. If the files have no path and no extension, that should still work fine (I would love to either have you check that, or give me an up to date HTML for me to check against). Shachar -- Shachar Shemesh Open Source integration consultant http://www.consumer.org.il/sun/ -- Shachar Shemesh Open Source integration consultant http://www.consumer.org.il/sun/ parse.pl Description: Perl program winxp_dll_map.html.bz Description: Binary data
Re: Windows API (What I have so far)
David Miller wrote: I checked my system for gdiplus.dll. It simply is not under c:\windows\system32, which is the path I gave when I made the sample HTML. It is under c:\windows\winsxs. The new program strips the path and dll extension in the HTML output. Would it be better to reverse that change, and include the path and extension to be compatible with your parser? I don't think that would be necessary. Just make sure that in the HTML you add a real NL after each (or otherwise make the interesting parts at most one per line), and that SHOULD work. My parser removed the path if it's there, and removes the extension if it's .dll. If the files have no path and no extension, that should still work fine (I would love to either have you check that, or give me an up to date HTML for me to check against). Shachar -- Shachar Shemesh Open Source integration consultant http://www.consumer.org.il/sun/
Re: Windows API (What I have so far)
Dave wrote: Thanks, I will look into merging the two together sometime soon, if no one beats me to it. First I want to make the existing program a little more readable before it becomes unmanageable and even I don't know what it does. :) The sample HTML I created was done from my laptop, which has all sorts of applications installed. There might be a lot of irrelevant information. It may become a much smaller table once it's run on a clean system. Please keep the foreend/backend approach, as I have neither tools nor environment to run your original perl prog, and I would still like to get the HTML rendering. I think the best approach is for a backend to dump the raw data into a easy to parse format (and your original format was, as you can see, not too difficult once you add the newlines), and a frontend that formats these into HTML. As for the unnecessaries - 238 columns is much better than I feered. More worriying than the sheer number is the warning my prog issues when run on your original input (like I said - I don't have any other): DLL fsusd depends on DLL gdiplus, which does not exist DLL photowiz depends on DLL gdiplus, which does not exist DLL shmedia depends on DLL gdiplus, which does not exist DLL webvw depends on DLL gdiplus, which does not exist DLL wiadefui depends on DLL gdiplus, which does not exist DLL wiavideo depends on DLL gdiplus, which does not exist DLL wiavideo depends on DLL gdiplus, which does not exist DLL wiavusd depends on DLL gdiplus, which does not exist Manually checking that with your output reveals that to be a correct assesment (i.e. - not a bug). there are references to a DLL called "gdiplus", which does not itself show in the output. Care to check your system and find out how that came about? Shachar At 01:11 AM 2/9/2003 +0200, you wrote: Attached is a perl prog that taked David's original HTML output with a single necessary preprocessing (replacing each with \n), and issues a list of the DLLs (no deps as of yet) in the order discussed before (i.e. - A depends on B -> A is higher, A has more dependants than B -> A is higher). I will now work on displaying this in a table. Shouldn't be too difficult (the fact that the table will be 238 coloumns wide nonwithstanding). Could be worse. The table is 1141 lines long. This does not work with David's new prog yet, but as the both of them are in perl I am sure it will not be too big a deal to merge the two progs into one. This will just simplify the process of getting the initial input (currently parsed from the HTML). Shachar Shachar Shemesh wrote: Havn't had a chance to look at your script yet, but I am two hours' work away from something that parses the original HTML you gave, and outputs the monster in the form Dimi and I suggested. I will attach it later today, and then you can merge the two, if you like. Shachar Quoting David Miller <[EMAIL PROTECTED]>: I thought a few of you might be interested in the current status of this script, so here is an update. I will attach a copy in case anyone wants to test it, or add functionality or fixes. I'd be interested in the results of any tests, especially if you discover any parsing errors. It is far from complete, but at this stage does the following: - Scan a given path, locating all dll files - Generate an HTML map of dll imports only (sorted, lowercase, stripped of paths) - dumpbin /import and dumpbin /export on all dll files and save the results in imports.txt and exports.txt respectively - parse imports.txt as follows, and save the results in imported_api.txt: DLL nameimported DLLimported API - parse exports.txt as follows, and save the results in exported_api.txt: DLL nameexported API Future plans: - Create a matrix of data currently in HTML map - Generate HTML cross reference of all imported/exported API - Implement dumping of data into a database (Something queryable, but what?) - Detect and report unimplemented APIs in wine -- Shachar Shemesh Open Source integration consultant http://www.consumer.org.il/sun/ -- Shachar Shemesh Open Source integration consultant http://www.consumer.org.il/sun/
Re: Windows API (What I have so far)
Attached is a perl prog that taked David's original HTML output with a
single necessary preprocessing (replacing each with \n), and
issues a list of the DLLs (no deps as of yet) in the order discussed
before (i.e. - A depends on B -> A is higher, A has more dependants than
B -> A is higher).
I will now work on displaying this in a table. Shouldn't be too
difficult (the fact that the table will be 238 coloumns wide
nonwithstanding). Could be worse. The table is 1141 lines long.
This does not work with David's new prog yet, but as the both of them
are in perl I am sure it will not be too big a deal to merge the two
progs into one. This will just simplify the process of getting the
initial input (currently parsed from the HTML).
Shachar
Shachar Shemesh wrote:
Havn't had a chance to look at your script yet, but I am two hours' work away
from something that parses the original HTML you gave, and outputs the monster
in the form Dimi and I suggested. I will attach it later today, and then you
can merge the two, if you like.
Shachar
Quoting David Miller <[EMAIL PROTECTED]>:
I thought a few of you might be interested in the current status of this
script, so here is an update. I will attach a copy in case anyone wants
to
test it, or add functionality or fixes. I'd be interested in the
results of
any tests, especially if you discover any parsing errors.
It is far from complete, but at this stage does the following:
- Scan a given path, locating all dll files
- Generate an HTML map of dll imports only (sorted, lowercase, stripped
of
paths)
- dumpbin /import and dumpbin /export on all dll files and save the
results
in imports.txt and exports.txt respectively
- parse imports.txt as follows, and save the results in
imported_api.txt:
DLL nameimported DLLimported API
- parse exports.txt as follows, and save the results in
exported_api.txt:
DLL nameexported API
Future plans:
- Create a matrix of data currently in HTML map
- Generate HTML cross reference of all imported/exported API
- Implement dumping of data into a database (Something queryable, but
what?)
- Detect and report unimplemented APIs in wine
--
Shachar Shemesh
Open Source integration consultant
http://www.consumer.org.il/sun/
parse.pl
Description: Perl program
Re: Windows API (What I have so far)
Havn't had a chance to look at your script yet, but I am two hours' work away from something that parses the original HTML you gave, and outputs the monster in the form Dimi and I suggested. I will attach it later today, and then you can merge the two, if you like. Shachar Quoting David Miller <[EMAIL PROTECTED]>: > I thought a few of you might be interested in the current status of this > script, so here is an update. I will attach a copy in case anyone wants > to > test it, or add functionality or fixes. I'd be interested in the > results of > any tests, especially if you discover any parsing errors. > > It is far from complete, but at this stage does the following: > > - Scan a given path, locating all dll files > - Generate an HTML map of dll imports only (sorted, lowercase, stripped > of > paths) > - dumpbin /import and dumpbin /export on all dll files and save the > results > in imports.txt and exports.txt respectively > - parse imports.txt as follows, and save the results in > imported_api.txt: > > DLL nameimported DLLimported API > > - parse exports.txt as follows, and save the results in > exported_api.txt: > > DLL nameexported API > > Future plans: > > - Create a matrix of data currently in HTML map > - Generate HTML cross reference of all imported/exported API > - Implement dumping of data into a database (Something queryable, but > what?) > - Detect and report unimplemented APIs in wine >
Re: GDI question
Mike Hearn wrote: Yeah, the GDI is slow. I'd be interested to see a quote from one of the Wine-based companies. How much slower is it? I know it'll be slower than the MS native implementation simply because it's not been fully optimized, but most apps I run under Wine have perfectly acceptable graphics performance. The most noticable problems are related to flickering in fact. Are we talking raw API performance or real world stuff that users would notice? There used to be a benchmark suite called "Winbench", that tried to load real world applications and see how fast the performed various operations. Anyone has a recent version? Shachar
Re: Windows API database / map
Dimitrie O. Paun wrote: 4. Remove the columns from the matrix that have no X's. No X's mean noone is linking to it, and it links to noone. I would like to know of its existance, even if it is unlinked. Let's also not forget that some modules (lpk.dll, for example) are only linked to dynamically (due to circular dependancy from GDI32). 5. Order columns by order of importance. That is, the ones with more X's come first. No, order them by order of dependancy. I.e. - I want to know that if a DLL links to a DLL that is below it in the list, it is a circular dependancy. There is a standard matrix view that looks something like this: ntdll advapi32 user32 kernel32 msvcrt advapi32 user32 kernel32 X X X msvcrt X X Ordering should be done by the following criteria: 1. If A depends on B, but B does not depend on A, A must appear higher than B. 2. If rule 1 did not resolve relative order, and A has more modules dependant on it than B, A must appear higher. 3. If neither rules resolved the order, make it arbitrary. These two criteria make sure that the matrix is triangle shaped unless there's a circular dependancy. Also, these rules make sure that modules that depend on other modules and are heavily linked to, such as kernel32, are higher up than modules that depend on no other modules and are not linked to, such as actxprxy. If you want, I can write some perl to create such a table from the available information. Shachar
Re: Wineconf 2003
Jeremy White wrote: For where, I would think it's time to hold it in Europe. Hear hear. I doubt I'll be able to afford a plane ticket to the U.S. at this stage of my life (turning to the independant life and all). Shachar
Re: Scrollbars misplaced in several apps
Duane Clark wrote: Hmmm... I thought I remembered maybe 6 months ago or so a discussion about this... ahh yes between you and Dmitry :-) http://www.winehq.com/hypermail/wine-devel/2002/11/0463.html So does this mean you are going to create a separate wordpad, as you mentioned then? The concensus then was that Notepad will use Rich Edit because we need to support RTFs. However, noone seemed to bother writing even the simplest decoder for it. On the other hand, I need notepad to support a font dialog because of non-Western codepages issues. As a result, I decided to just submit the patch and turn it back into EDIT. If anyone wants to start working on an editor (or even a viewer) that supports RTFs, they can either: * Fork notepad or * Figure out how to maintain the font dialog support under rich edit. Until someone decides that RTFs are important enough to actually do anything about them, I don't see any reason why a simple fix such as the font dialog should wait. Shachar
Re: Scrollbars misplaced in several apps
Duane Clark wrote: Were you perhaps using Window's notepad rather than Wine's? I see it with Wine's notepad. I also see it in Actel designer, that I remember. And I guess I should have said richedit rather than richtext... oh well. In all cases that I have seen, it is fixed by using a native richedit dll. Window's notepad uses the usual EDIT control. As of a few days ago, however, so does the Wine notepad. This may explain the inconsitancy. http://cvs.winehq.com/patch.py?id=7152 Shachar
Re: PATCH: Get rid of superfluous dup() and close() calls.
David Laight wrote: I'm not sure I agree. When someone closes a fd they shouldn't, that would lead to program crashing, and attention being brought to the problem. When someone leaks a fd, noone will notice. No, it causes horrid corruptions that are particularly difficult to find. What happens is that someone else does an open() and is given the number of the (incorrectly) closed fd. The owener of the fd will then write into the newly opened file. This can happen if a 'normal' program does close(0), close(1), close(2) then much later accidentally calls printf() instead of sprintf(). When the stdio buffer is eventually flushed data is written to what has been reopened as fd0. (This was a real bug in software that got released...) David What happens under Windows with such circumstances? Sh.
Re: ReactOS cmd exe (was Re: Explorer)
Tony Lambregts wrote: Steven Edwards wrote: Our cmd.exe is based off of freedos command.com which is GPL. Dang! Can someone please explain to me why our winelib apps MUST be LGPL? What is the reason wcmd cannot be GPL? Where is the violation? Well, we can at least ask. Do you know who to contact? Wouldn't that mean that wcmd be a Dos program? Isn't that inferior to a "Win32" program that wcmd currently is? Shachar
