October 2003 - Wine-Devel - list.winehq.org

Re: Summary of translations
by Vincent Béron Oct. 21, 2003

Oct. 21, 2003

Le mar 21/10/2003 à 14:45, Hans Leidekker a écrit : > This is certainly useful for me, as I was just about to start translating > some dlls to dutch. I checked the page you mention above and it showed > there are some parts missing from dlls that already haven been translated > to dutch. I don't think I would have found those otherwise (I wouldn't have > gone looking for them). So I think this tool can certainly prove valuable in > keeping resources up to date. That's why I did it (after I saw Dimi's output). Although now, all French resources seem to be translated... :) Glad to know it helped you too. > > And now for some criticisms. I can understand that you only check languages > for which at least one resource exists because otherwise the table would grow > large and show lots of empty cells for years to come, but the first thing I need > to set out translating is a list of dlls that have translatable resources, which I > now obtain by doing: > > [wine-src] $ find dlls -name "*En.rc" > > Which is crude and depends on a file naming convention. Maybe your tool > could help here too. If there's an html file, the dll contains some resources. Now, not all resources are translatable (icons, cursors, bitmaps we probably don't care, not sure about versioninfo). That can be integrated in the tool too. For now, if there's only a LANG_NEUTRAL version of a resource, it doesn't complain, else it creates the file. > > Second, those filenames for the html output really aren't fit to be served > by apache. They're truncated in a directory listing page so I have to hover > the links to be able to find a particular file. I think you need to either split > them into directories or provide an index page. As Dimi pointed out, all on a single page would be better. Or a couple of pages, with AAFRIKANS-GERMAN on one, HUNGARIAN-SLOVAK, etc. to prevent the table from being too wide, and marking only the relevant languages (ie, those for which at least one translated resource exists). Another thing is languages for which more than one sublanguage is used, such as Chinese. > > Third, I think you should sort the table columns alphabetically by language > name. But they're sorted! Ok, by language ID :) Good idea. > > Lastly, Konqueror doesn't render those popup/layer thingies well, and in > Mozilla I can't can rid of a popup once I clicked a link (well, I can press > the Back button, but that's non-intuitive to say the least). To be honest I > think they're overkill. Make them a regular link. Remember, you said all > comments were welcome ;-) No problem with that. I tried to get the same feeling as Mozilla's Tinderbox, but I can make them regular links instead. Or "tooltips". Vincent

1 0

Re: NTFS driver (was: ReactOS GPL vs. proprietary drivers)
by Szakacsits Szabolcs Oct. 21, 2003

Oct. 21, 2003

> > Let me tell an example, the (Linux) NTFS driver supports transparent > > compression. Today CPU's are very fast and the disk bandwidth is very > > slow compared. So doing bulk data transfers, the disk bandwidth is the > > bootleneck. Would you be faster using the filesystem's transparent > > compression? In theory yes, CPU can [de]compress when transfering data > > and you must also transfer less data. No main Linux fs supports this, > > hopefully Reiser4 will in the future ... (there was hope for e2compr as > > well for many years but it didn't work out after all). > > ext2 have supported this for ages, check out chattr(1),lsattr(1) This feature is reserved for about 8 years. But it never worked reliable. Google for the story. I wrote above the keyword (e2compr). > In what way are the compression features in NTFS different? It works reliable since about 8 years. Something what none of the main Linux filesystem can do today (ext3, reiserfs, JFS, XFS). Szaka

1 0

Re: [Rebar] Don't store band text if "" is passed into SetBandInfo
by Huw D M Davies Oct. 21, 2003

Oct. 21, 2003

On Tue, Oct 21, 2003 at 07:24:31PM +0100, Robert Shearman wrote: > Hi, > > This makes IE look a bit neater. > > Rob > > Changelog: > - Don't store band text if "" is passed into SetBandInfo > @@ -3447,8 +3450,11 @@ > } > if (lprbbi->lpText) { > INT len = lstrlenW (lprbbi->lpText); > - lpBand->lpText = (LPWSTR)Alloc ((len + 1)*sizeof(WCHAR)); > - strcpyW (lpBand->lpText, lprbbi->lpText); > + if (len > 1) Shouldn't this be len >= 1 ? > + { > + lpBand->lpText = (LPWSTR)Alloc ((len + 1)*sizeof(WCHAR)); > + strcpyW (lpBand->lpText, lprbbi->lpText); > + } > } > } > Huw.

1 0

Re: Fix comctl32 conformance test
by Rolf Kalbermatter Oct. 21, 2003

Oct. 21, 2003

Alexandre Julliard <julliard(a)winehq.org> wrote: <Hans Leidekker <hans(a)it.vu.nl> writes: > >> It appears that the comctl32 conformance test calls functions by name >> that are exported by ordinal only on Windows. Still the test runs (and >> thus run-time links) on Wine. Is this wanted behavior? > >Yes it is, the functions are converted to ordinal imports by the >import library. The existing code works just fine, except when >cross-compiling on Mingw because the import libraries are broken >there. This should be fixed in Mingw not in Wine. Mmh! I have downloaded the PSDK from the MSDN site, and although it says Microsoft Platform SDK February 2003 in the Start menu it really was just downloaded one month ago and my comctl32.lib does not contain symbols for at least DPA_Create() and DPA_GetPtr() while it does contain most of the other DPA symbols. What am I missing here? Rolf Kalbermatter

3 2

Re: Emulate win98 by default
by Andreas Mohr Oct. 21, 2003

Oct. 21, 2003

Hi, On Tue, Oct 21, 2003 at 11:25:55AM +0100, Mike Hearn wrote: > IE setup needs this, and really, there's not much difference between > them. I would change this in the code, but I don't know where this key > is referenced. > > Emulate win98 and DOS 6.11 by default > > Index: documentation/samples/config > =================================================================== > RCS file: /home/wine/wine/documentation/samples/config,v > retrieving revision 1.52 > diff -u -r1.52 config > --- documentation/samples/config 16 Oct 2003 19:09:57 -0000 1.52 > +++ documentation/samples/config 21 Oct 2003 10:19:26 -0000 > @@ -77,9 +77,9 @@ > > [Version] > ; Windows version to imitate (win95,win98,winme,nt351,nt40,win2k,winxp,win2k3,win20,win30,win31) > -;"Windows" = "win98" > +"Windows" = "win98" > ; DOS version to imitate > -;"DOS" = "6.22" > +"DOS" = "6.22" Please DON'T do this. These are FORCED, GLOBAL values, as such they are highly evil (since that way the whole version detection mechanism gets disabled and many programs which need other values cannot have their version guessed properly any more). Instead, the default fallback values in the version code should probably be changed to refer to Win98 to make sure we do use Win98 in case we cannot guess any value (if they are not already, but they might still be at Win95). Note that the version code has some straw man default values which are NOT the real defaults if you analyse the code path properly. And if IE setup still doesn't run after having changed the default guesstimate to Win98, tough luck: you'll have to force version Win98 manually (or implement a smarter version detection mechanism that takes some observations and transforms them into a Win98 version value). And we should also indicate in the sample config file that actually setting these will override any and all intelligent(?) version detection mechanisms... (if only to prevent other people from attempting the same mistake as you ;) -- Open Source Software: because smart people know to prefer a multitude of Support Options to a Single Point of Failure commonly used software represents. (who's left to sue given your average all-denying End User License Agreements, or who to ask for support if a vendor or product decided to silently die away?)

2 1

EDIT_WM_Create fix.
by Rein Klazes Oct. 21, 2003

Oct. 21, 2003

Hi, Sent to wine-devel as well: this might break some odd edit controls that I did not catch. This fixes masked edit controls used by applications created by Power Builder, it fixes bug #807. Power builder depends on the return value of the WM_CREATE message by the EditWndProc to be != 0. Now I spent some time creating EDIT windows, varying parameters (with or without text), varying styles including multilines even tested the edit part of a combobox. In all cases the WM_CREATE message return value turned out to be 1. So at the very least this seems to be the common case, and not zero as in wine's implementation. So I propose to put that in, and if it breaks hope it will be caught. ChangeLog: controls : edit.c A WM_CREATE message sent to an Edit window procedure should return 1. Power Builder masked edit controls depend on it. Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 5

MDI windows, MDIClient and mdiclient
by Shachar Shemesh Oct. 21, 2003

Oct. 21, 2003

Hi all, I am trying to make an application work under wine. The app is probably an MFC app, that defenitely uses MDI. The problem boils down to this - it tries to create an MDI window by doing SendMessageA to a message of type "WM_MDICREATE". Here's the catch - the class it wants to use is in Unicode. This fails for obvious reasons. I'm trying to find my way around the MDI setting, and phrase a regression test. However, I cannot seem to create the exact same circumstances. When looking at the original app using Spy++, I see that the application has a window from the very start of the app (long before it sends WM_MDICREATE), which does not appear to have WS_EX_MDICHILD set, but which has a child window of class "MDIClient". Running the same app in Wine using --debugmsg +win,+class, I can see that it asks to open a window of class "mdiclient". I do not, however, see anywhere that such a class was ever registered! Furthermore - the call succeeds. Can anyone enlighten me? Is this window necessary whenever an MDI is present? If so, what function do I use on the parent window to tell it that it is to be an MDI container? Many thanks, Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/

4 15

Re: Fix comctl32 conformance test
by Alexandre Julliard Oct. 21, 2003

Oct. 21, 2003

Hans Leidekker <hans(a)it.vu.nl> writes: > It appears that the comctl32 conformance test calls functions by name > that are exported by ordinal only on Windows. Still the test runs (and > thus run-time links) on Wine. Is this wanted behavior? Yes it is, the functions are converted to ordinal imports by the import library. The existing code works just fine, except when cross-compiling on Mingw because the import libraries are broken there. This should be fixed in Mingw not in Wine. -- Alexandre Julliard julliard(a)winehq.com

2 1

suggestion, merge WINE and ReactOS MSVCRT
by Jonathan Wilson Oct. 21, 2003

Oct. 21, 2003

IMO its a waste for both WINE and ReactOS to have 2 different implementations of MSVCRT.DLL/CRTDLL.DLL Is there any valid reason not to either remove one and have both projects use the other or to merge both and come up with one dll?

2 1

Re: Fix tab size (3)
by Dimitrie O. Paun Oct. 21, 2003

Oct. 21, 2003

On October 19, 2003 07:41 pm, Vitaliy Margolen wrote: > Not true. Native uses default tab size of 96. > > - The minimum size of a tab is at least icon width + 3 if icon is present. > > - Prior observation that "under Windows, there seems to be a minimum width > of 2x the height for button style tabs" is not true. At least not in Win98. Brownie points for some conformance tests ... :) -- Dimi.

3 5

Instant crash with 20031016 - regression?
by Thomas Mertes Oct. 21, 2003

Oct. 21, 2003

Hello After compiling and installing Wine 20031016 it crashes instantly. Older versions up to 200309011 work without problems. Here is what I did: tm(a)penguin:~ > wine Speicherzugriffsfehler <--- Translation: Memory access error tm(a)penguin:~ > gdb wine GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-suse-linux"... (gdb) run Starting program: /usr/local/bin/wine Program received signal SIGSEGV, Segmentation fault. 0x4000d226 in _dl_signal_error () from /lib/ld-linux.so.2 (gdb) where #0 0x4000d226 in _dl_signal_error () from /lib/ld-linux.so.2 #1 0x4013e98e in _dl_sym () from /lib/libc.so.6 #2 0x4015f4b4 in dlsym_doit () from /lib/libdl.so.2 #3 0x4000d480 in _dl_catch_error () from /lib/ld-linux.so.2 #4 0x4015f7e0 in _dlerror_run () from /lib/libdl.so.2 #5 0x4015f473 in dlsym () from /lib/libdl.so.2 #6 0x3c001e02 in __pthread_initialize () at ../scheduler/pthread.c:763 #7 0x3c001e68 in init () at ../scheduler/pthread.c:770 #8 0x3c001ec9 in __do_global_ctors_aux () #9 0x3c001022 in _init () #10 0x4005dc34 in __libc_start_main () from /lib/libc.so.6 (gdb) q tm(a)penguin:~ > gcc --version 2.95.3 tm(a)penguin:~ > uname -a Linux penguin 2.4.4-64GB-SMP #1 SMP Wed May 16 01:20:45 GMT 2001 i686 unknown tm(a)penguin:~ > Btw: My system is Suse Linux version 7.2. Greetings Thomas -- NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++

1 0

Window refresh problem with GroupBox and Tabs
by George Marshall Oct. 21, 2003

Oct. 21, 2003

Hi I've already submitted this bug to the wine bugzilla but I'm posting it here as well 'cause... oh well you know. Pls. look at the end of the message for .gifs Bug 1689 follows: I've got an application which purpose is to just reproduce the wine bug I'm gonna explain below. There is, basically, a window, a tab control with four tabs, some GroupBoxes and a few editboxes. (Please, see the attached .gif to get an idea). Here we go with the interesting part... If you run the application you'll realize that some editboxes are not drawn at all and some other not correctly drawn (Expecially if you go through the tabs...) Now if you minimize and then raise this window or drag part of it out of the screen and then back in, everything in it is correctly "painted". The pic tabwin_ok.gif shows the application correctly drawn, while in tabwin_bad.gif you'll see the application in its bad behavior (Like described above). Another interesting thing to note is that if you go through the tabs backward( from the last one to the first one ) the window contents is correctly drawn, not if you go from the first tab to the last one. This is always reproducible. This bug is 100% reproducible with Wine 20030813, 20030709, 20030618 (the versions I could work with...) I'm actually trying to fix this by myself (an ugly workaround will do the job as well) but any help to get me to the right direction will be appriciated. You're more than welcome to ask for any debug or strace log. Thanks. http://bugs.winehq.org/attachment.cgi?id=359&action=view http://bugs.winehq.org/attachment.cgi?id=360&action=view

2 2

Re: will it?
by Ivan Leo Murray-Smith Oct. 20, 2003

Oct. 20, 2003

Wine can't load windows drivers. This may be possible in a very very far future, but it would probably be easier to write native drivers. Probably by the time wine can do such a thing, all hardware vendors will support linux anyway.

1 0

import and export tables
by Dave Miller Oct. 20, 2003

Oct. 20, 2003

A .tar.gz containing HTML tables of imports and exports for windows dlls is now available here: http://24.229.94.2/import_export_tables.tar.gz It is about 1MB but it will decompress to 1000+ html files and 58MB! I have not included empty tables where a dll does not import or export any functions. If you spot a missing windows dll, or a non-windows dll please let me know so I can add/remove as necessary. Of course feature requests are welcome as well. ------------------------------------- So many Right-wing Christians. So few lions.

1 0

Re: [ros-kernel] about headers
by Steven Edwards Oct. 20, 2003

Oct. 20, 2003

This is really the heart of the issue. Can we work out a system that will work for all projects involved? What I am about to bring up is not the same issues that Danny has with GCCisms but it has made me think about our build system again. WINE and Mingw both make use of some of the aspects of the GNU toolchain that ReactOS currently does not. I think I have a more simple solution to our problem but most of the ReactOS will not like it. Currenly the ReactOS project has a bad habit of importing libraries that we need such as zlib and freetype in to our funky build system. Then on top of that you heep on the problems of trying to support the w32api and WINE and you get the current cluster-fu*k we have now. 1. Create vendor branches for w32api, WINE and other projects that ReactOS needs. - Now the question becomes how do we structure this? If we use the w32api with the SDK/DDK then we can import it in to the WINE source tree just as we have done with freetype and zlib. 2. Can we import a vendor branch in to CVS under a existing repostory? - If the answer is yes then we do we need to import the whole WINE sourcetree only selected DLL and Programs. 3a. If we can do all of this then do we switch to a GNU configure system so we can configure all of the modules at compile time and dump our funky build system? - I am thinking a layout like this: /CVSROOT /reactos configure /contrib /w32api/configure /freetype/configure /OpenSSL/configure /zlib/configure /WINE/configure /dlls /programs /libs 3b. Or do we leave CVS like it is now? and maybe move the external libs to there own modules where we can Vendor branch them? - Moving to a GNU configure system would still make it easy on us. The only thing is we would need to create a set of import scripts for branching/merging and move the external libs to there own module CVSROOT/ /reactos /rosapps /WINE /support /w32api /freetype /zlib /openssl Ok I am sorry I have taken the discussion beyond headers but we have to find a solution that will work. Is w32api that solution? Does out current build system do everything we need to be able to scale? How does KDE or GNOME handle this? Thanks Steven --- Danny Smith <dannysmith(a)clear.net.nz> wrote: > As far as the mingw runtime headers are concerned, you will have a > hard > time convincing me to remove all the ISO C99 extras. You will also > have > a hard time convincing me that removal of all the POSIX-isms is a > good > thing, since they really assist building of things like binutils, > gcc, > libiconv, gettext, make, etc. > > As someone who has had input into the maintenace of gcc compiler > suppor > for mingw, > the hardest things to maintain are the MS-extensions (dllimport being > the worst because of the ambiguity of the syntax). Adherence to the > MS > "gold standard" has meant that mingw is forced to use sjlj exceptions > rather than DWARF2. > > Personally, I would prefer that mingw gcc/binutils move closer to > theFSF > mainstream > rather than drifting from it. Likewise, I would prefer that mingw > runtime moves in dirction towards ISO C, C++ conformance (eg, make > the C > headers namespace aware when in C++) rather than towards MS > conformance. > > Speaking for myself only. > > Danny __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

3 4

Re: ReactOS GPL vs. proprietary drivers - NTFS Driver under Linux + WINE
by Steven Edwards Oct. 20, 2003

Oct. 20, 2003

Hello Jan, Comments are inline. --- Jan Kratochvil <rcpt-ros-kernel.AT.reactos.com(a)jankratochvil.net> wrote: > Hi, > > As GPLed Linux-NTFS still has no NTFS r/w capability I completed the > project > for reliable r/w access in Wine way by using MS-Windows ntfs.sys > driver. > > Captive-NTFS > http://www.jankratochvil.net/ I have forwarded this reply to wine-devel as they my find captive NTFS interesting > My project is GPL-2.0 and it incorporates ReactOS kernel sources > currently also > carrying GPL-2.0 license. There are rumours GPL may be problem for > linking with > proprietary code (ntfs.sys&ntoskrnl.exe). I interpret it as GPL only > affects > _distribution_ of the program while no proprietary code is > distributed with my > package. Proprietary code is only run-time linked by the end-user. > > > In a GPL-related discussion here two monts ago ReactOS developers > were open for > reusal of existing proprietary drivers for ReactOS as one of the > significant > feature of ReactOS. I would like an affirmation from the major > ReactOS > developers they are not going to try to sue me for releasing Captive > NTFS. I dont think you have to worry about any ReactOS developers filing suit. I would be more worried about one from Microsoft =). In fact I am very happy to see this. I would like to see the interface you have developed evolve in to a a full compatiblty layer addon for WINE so they can support other drivers. I must confess I have not had a chance to look at the code but if it works as you say then this is great news! If you dont distribute Captive NTFS with a Microsoft NTFS driver then you should not have a problem. You are correct the GPL seems to only cover distribution not use. Thanks Steven __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

1 0

will it?
by John Smith Oct. 20, 2003

Oct. 20, 2003

now that windows drivers will work in linux, can wine run directx easy? with wine on linux, and having windows drivers, the wine shouldn't have any troubles whatsoever acting as windows

1 0

Re: MDI windows, MDIClient and mdiclient
by Fabian Cenedese Oct. 20, 2003

Oct. 20, 2003

>I'm trying to see why a propritery program misbehaves under wine, by comparing it to Windows. When running it under Windows, I don't have the luxury of OutputDebugString. Maybe even better: http://www.codeproject.com/useritems/DLL_Injection_tutorial.asp Already with a sample about logging winsock functions. bye Fabi

1 0

Re: named pipes problem?
by Alexandre Julliard Oct. 20, 2003

Oct. 20, 2003

Daniel Marmier <d.marmier(a)bluewin.ch> writes: > Are you talking about support for TLS in wine? > If so, is that already assigned? No, the problem is TLS support in glibc itself, since that bypasses our pthread wrappers. We don't need to use glibc-style TLS in Wine since we can use the Win32 TLS support instead. -- Alexandre Julliard julliard(a)winehq.com

2 1

named pipes problem?
by Gregory M. Turner Oct. 20, 2003

Oct. 20, 2003

Does everybody's kernel32 named pipes test pass (in wine)? Named pipes are acting very wierd here, lots of segfaults and other wierdness... the test seems to freeze attempting to create the alarmThread in test_NamedPipe_2 (test 3 of 4). The wineserver holds up OK, but the client side looks a mess. This is similar to other behavior I see in other contexts... perhaps, the pattern is, after I create a named pipe, subsequent calls to CreateThread never return or cause segfaults and general instability. Am I the only one? The following is a snippet from "strace -f wine kernel32_test.exe.so pipe" where wine starts to go south.... [pid 28568] write(1, "pipe.c:459:", 11pipe.c:459:) = 11 [pid 28568] write(1, "exercizeServer starting\n", 24exercizeServer starting ) = 24 [pid 28568] write(1, "pipe.c:470:", 11pipe.c:470:) = 11 [pid 28568] write(1, "Client connecting...\n", 21Client connecting... ) = 21 [pid 28568] rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8) = 0 [pid 28568] writev(4, [{"\207\0\0\0\222\0\0\0\0\0\0\0\0\0\0\300\0\0\0\0\0\0\0\0"..., 64}, {"\\\0\\\0.\0\\\0P\0i\0P\0e\0\\\0t\0e\0s\0t\0s\0_\0.\0"..., 146}], 2 <unfinished ...> [pid 28570] <... poll resumed> [{fd=5, events=POLLIN}, {fd=4, events=POLLIN}, {fd=7, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}, {fd=13, events=POLLIN}, {fd=15, events=POLLIN}, {fd=16, events=POLLIN, revents=POLLIN}, {fd=-1}, {fd=-1}, {fd=-1}, {fd=-1}, {fd=-1}, {fd=-1}, {fd=24, events=POLLIN}, {fd=23, events=POLLIN}], 16, -1) = 1 [pid 28570] read(16, "\207\0\0\0\222\0\0\0\0\0\0\0\0\0\0\300\0\0\0\0\0\0\0\0"..., 64) = 64 [pid 28570] read(16, "\\\0\\\0.\0\\\0P\0i\0P\0e\0\\\0t\0e\0s\0t\0s\0_\0.\0"..., 146) = 146 [pid 28570] write(17, "\17\0\0\300\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 [pid 28570] poll( <unfinished ...> [pid 28568] <... writev resumed> ) = 210 [pid 28568] read(5, "\17\0\0\300\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64 [pid 28568] rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 [pid 28568] write(1, "pipe.c:481:", 11pipe.c:481:) = 11 [pid 28568] write(1, "connect failed, retrying\n", 25connect failed, retrying ) = 25 [pid 28568] gettimeofday({1066424342, 296207}, NULL) = 0 [pid 28568] gettimeofday({1066424342, 296363}, NULL) = 0 [pid 28568] select(0, NULL, NULL, NULL, {0, 199844} <unfinished ...> [pid 28575] --- SIGSTOP (Stopped (signal)) @ 0 (0) --- [pid 28574] --- SIGSTOP (Stopped (signal)) @ 0 (0) --- [pid 28575] modify_ldt(17, {entry_number:40, base_addr:0x40af3000, limit:4095, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:0, seg_not_present:0, useable:0}, 16 <unfinished ...> [pid 28574] modify_ldt(17, {entry_number:39, base_addr:0x408c3000, limit:4095, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:0, seg_not_present:0, useable:0}, 16 <unfinished ...> [pid 28575] <... modify_ldt resumed> ) = 0 [pid 28574] <... modify_ldt resumed> ) = 0 [pid 28575] sigaltstack({ss_sp=0x408d1000, ss_flags=0, ss_size=1048576} <unfinished ...> [pid 28574] brk(0 <unfinished ...> [pid 28575] <... sigaltstack resumed> , NULL) = 0 [pid 28574] <... brk resumed> ) = 0x3c009000 [pid 28575] rt_sigaction(SIGINT, {0x40081bf2, [INT USR2], SA_RESTORER|SA_STACK|SA_RESTART, 0x45a14eb8}, <unfinished ...> [pid 28574] brk(0x3c00a000 <unfinished ...> [pid 28575] <... rt_sigaction resumed> NULL, 8) = 0 [pid 28574] <... brk resumed> ) = 0x3c00a000 [pid 28575] rt_sigaction(SIGFPE, {0x40081b76, [INT USR2], SA_RESTORER|SA_STACK|SA_RESTART, 0x45a14eb8}, <unfinished ...> [pid 28574] sigaltstack({ss_sp=0x406a1000, ss_flags=0, ss_size=1048576} <unfinished ...> [pid 28575] <... rt_sigaction resumed> NULL, 8) = 0 [pid 28574] <... sigaltstack resumed> , NULL) = 0 [pid 28575] rt_sigaction(SIGSEGV, {0x40081aa4, [INT USR2], SA_RESTORER|SA_STACK|SA_RESTART, 0x45a14eb8}, <unfinished ...> [pid 28574] rt_sigaction(SIGINT, {0x40081bf2, [INT USR2], SA_RESTORER|SA_STACK|SA_RESTART, 0x45a14eb8}, <unfinished ...> [pid 28575] <... rt_sigaction resumed> NULL, 8) = 0 [pid 28574] <... rt_sigaction resumed> NULL, 8) = 0 [pid 28575] rt_sigaction(SIGILL, {0x40081aa4, [INT USR2], SA_RESTORER|SA_STACK|SA_RESTART, 0x45a14eb8}, <unfinished ...> [pid 28574] rt_sigaction(SIGFPE, {0x40081b76, [INT USR2], SA_RESTORER|SA_STACK|SA_RESTART, 0x45a14eb8}, <unfinished ...> [pid 28575] <... rt_sigaction resumed> NULL, 8) = 0 [pid 28574] <... rt_sigaction resumed> NULL, 8) = 0 from there it just degrades into a soup of SIGSEGV and rt_sigprocmask(), like: [pid 28575] --- SIGSEGV (Segmentation fault) @ 0 (0) --- [pid 28574] <... rt_sigprocmask resumed> NULL, 8) = 0 [pid 28575] rt_sigprocmask(SIG_UNBLOCK, ~[], <unfinished ...> [pid 28574] --- SIGSEGV (Segmentation fault) @ 0 (0) --- [pid 28575] <... rt_sigprocmask resumed> NULL, 8) = 0 [pid 28574] rt_sigprocmask(SIG_UNBLOCK, ~[], <unfinished ...> [pid 28575] --- SIGSEGV (Segmentation fault) @ 0 (0) --- [pid 28574] <... rt_sigprocmask resumed> NULL, 8) = 0 [pid 28575] rt_sigprocmask(SIG_UNBLOCK, ~[], <unfinished ...> [pid 28574] --- SIGSEGV (Segmentation fault) @ 0 (0) --- [pid 28575] <... rt_sigprocmask resumed> NULL, 8) = 0 [pid 28574] rt_sigprocmask(SIG_UNBLOCK, ~[], <unfinished ...> [pid 28575] --- SIGSEGV (Segmentation fault) @ 0 (0) --- [pid 28574] <... rt_sigprocmask resumed> NULL, 8) = 0 [pid 28575] rt_sigprocmask(SIG_UNBLOCK, ~[], <unfinished ...> this never ends. Attaching to various threads (when I am so lucky as to be able to) is not very instructive (to me ;)). -- gmt

3 6

Re: S3 texture compression patent
by Ivan Leo Murray-Smith Oct. 20, 2003

Oct. 20, 2003

>Is it a patent for a hrdware solution, or for software? If software then in >Europe, at least in Germany and others, it wouldn't matter because >softwarepatents are not possible (and hopefully never will). Software patents are illegal in all the EU, and it will stay like that thanks to the latest copyright directive, the EUCD. Also, this thread should be on wine-license. It wouldn't be hard to host wine in the EU, codeweavers can just get some host space from any EU hoster, and set up and publish remotely.

3 3

Asprotected programs crash with current wine-cvs
by Oleg Prokhorov Oct. 20, 2003

Oct. 20, 2003

Hello Alexandre , current CVS version has regression. All Asprotected (probably) programs crash due to the fact that Asprotect assumes that executables are being loaded from kernel32.dll, so stack return address passed to executable entry (in the other words executable entry was called from kernel32.dll) points to somewhere inside kernel32.dll. Later Asprotect uses this return address to detect kernel32.dll export section and dig it for required kernel32.dll function (LoadModule, VirtualAlloc etc). The problem is that now executable entry loaded under wine is being started from somewhere inside ntdll.dll, so Asprotected kernel32.dll function finding routines fail with crash. I'm not sure what's the best way to solve it, is some ntdll.dll process startup code relocating to kernel32.dll good enough ? -- Best regards, Oleg mailto:xolegpro(a)rbcmail.ru

1 0

RE: WWN: wn20031017_192.xml
by Brian Vincent (C) Oct. 20, 2003

Oct. 20, 2003

> Test these lines > BEGIN { FS = "\"" } > { A+=$2 } > { B+=$4 } > END { print "<person posts=\""A"\""" size=\"" B"\""" > who=\""$6"\" />" } Works like a charm! Thanks! --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

1 0

Re: S3 texture compression patent
by Ivan Leo Murray-Smith Oct. 19, 2003

Oct. 19, 2003

>But what would that mean for the developers in the US? Just because the >sources are hosted in EU would still render them useless for US developers. No, if you're in the US and publish something in the EU, you aren't violating any US law, as you aren't publising anything in the US. If this isn't the case, the US constitution must have a few bugs in it. This would also mean moving the mailing list archives and the CVS to the EU, but I don't think this will happen, unless you show that there is a patent violation and that wine will never work without violating that patent.

2 1

Re: Setupapi Win16/32 (Again) and PSDK porting fixes
by Gregory M. Turner Oct. 19, 2003

Oct. 19, 2003

On Saturday 18 October 2003 01:57 pm, Steven Edwards wrote: > With this > patch all of the objects for setupapi.dll can be built on > MS_VC with the PSDK. There are a few minor issues but nothing > to major doesn't this: -typedef struct _CABINET_INFOA { +typedef struct _CABINET_INFO_A { PCSTR CabinetPath; PCSTR CabinetFile; PCSTR DiskName; USHORT SetId; USHORT CabinetNumber; -} CABINET_INFOA, *PCABINET_INFOA; +} CABINET_INFO_A, *PCABINET_INFO_A; -typedef struct _CABINET_INFOW { +typedef struct _CABINET_INFO_W { PCWSTR CabinetPath; PCWSTR CabinetFile; PCWSTR DiskName; USHORT SetId; USHORT CabinetNumber; -} CABINET_INFOW, *PCABINET_INFOW; +} CABINET_INFO_W, *PCABINET_INFO_W; mean we should do this: -DECL_WINELIB_TYPE_AW(CABINET_INFO); -DECL_WINELIB_TYPE_AW(PCABINET_INFO); +DECL_WINELIB_TYPE_AW(CABINET_INFO_); +DECL_WINELIB_TYPE_AW(PCABINET_INFO_); ? -- gmt "class 'SfxPoolCancelManager' only defines a private destructor and has no friends" -- gcc, resorting to unnecessary character attacks

2 3