September 2010 - Wine-Devel

Re: Console issues in recent git

by Austin English

On Thu, Sep 2, 2010 at 2:44 PM, Jerome Leclanche <adys.wh(a)gmail.com> wrote: > To be more specific, it happens on any and every wine program. I see it as well, though an easy workaround is to run 'reset'. After that, terminal returns to normal. -- -Austin

Sept. 2, 2010

Re: msxml3: IXMLDOMText_get_text return trimmed text when XML_TEXT_NODE

by Octavian Voicu

On Thu, Sep 2, 2010 at 1:52 PM, GOUJON Alexandre <ale.goujon(a)gmail.com>wrote: > On 09/02/2010 12:10 PM, Alexandre Julliard wrote: > >> That's ugly and inefficient, especially since the common case is to not >> modify it. >> >> > Well, in fact I don't modify the content. > I just trim the output of bstr_from_xmlChar( xmlNodeGetContent( > (xmlNodePtr)This->node ) ) > And I made a separate function to not overload xml_get_text. > I think what Alexandre J means is that you are reallocating the buffer every time (even if there is no whitespace to trim), which is inefficient for the average case (in which there will be no whitespace to trim). You only have to reallocate the string if (j - i < len - 1). You could also try this hack: you don't have to reallocate the string even if it has whitespace, use memmove to get rid of the leading whitespace, then just set the string's length to j - i + 1. Not sure if it makes sense to reallocate the string if it's empty. Octavian

Sept. 2, 2010

Re: RFC: Compiling as 16 bit

by Alexandre Julliard

Morten Rønne <morten.roenne(a)tdcadsl.dk> writes: > That struct is already defined in wine/winbase16.h as PDB16. > > So I would like to do this in my test program: > #include <wine/winbase16.h> > PDB16 *psp; > > In a perfect world this would be enough to have full access to the > PDB16 struct in the test program. > But alas, the world is not perfect (yet). You can't do that. You need to have appropriate 16-bit headers for the basic Windows stuff, this should come with the compiler. For undocumented structures and the like, you have to define them yourself. -- Alexandre Julliard julliard(a)winehq.org

Sept. 2, 2010

Re: [1/3] dsound: Add support for 32-bit IEEE float buffers

by Chris Robinson

On Thursday, September 02, 2010 1:38:29 pm Owen Rudge wrote: > These patches add support to DirectSound that allow the conversion of > 32-bit IEEE float audio buffers to PCM. Some games (e.g., Call of Duty > 5) output their audio in this format, and media players such as > foobar2000 have support for it too. You'll probably want to make sure the float values are clamped between -1 and +1 before converting, otherwise they'll wrap and cause bad static noise.

Sept. 2, 2010

Re: Console issues in recent git

by PleegWat

On 09/02/2010 09:41 PM, Eric Pouech wrote: > Le 02/09/2010 03:29, Jerome Leclanche a écrit : >> Anyone else's terminal emulators really acting up since the last git >> batch? On konsole (2.5//4.5.00), I'm unable to see what I'm writing if >> there is a wine process running, until it's killed. This is probably a >> konsole bug, but still... >> >> CC eric. >> >> -- >> J. Leclanche >> >> > not really > is the program you're running a CUI or GUI exec ? > if it's a CUI, then it's normal as it's supposed to get all your current > input > if it's a GUI (without a win32 console), then it's more questionnable > > A+ > I'm getting this problem as well, and I did a quick test - it also affects notepad and winecfg, although in those cases both the prompt and proper terminal function come back when the program exits. For many games, the prompt comes back shortly after the game was fully loaded. For these proper terminal function is not restored. Could it be that a fork() is happening somewhere, and that the child (rather than the parent) tries to restore the terminal on exit? And I'm not 100% on how this works in windows, but should the prompt be coming back at all before the program has exited? Could someone test this? Two programs I know this happens with are World of Warcraft and Starcraft 2. PleegWat

Sept. 2, 2010

Re: banning spammer from the forum

by Gert van den Berg

For the forum it might be useful to find / write a phpbb extension that disallows URL shortening services (and known spam domains) and forces a captha check on users posting ANY link to a non-whitelisted domain... (pastebin, a decent image hosting service, winehq, microsoft, codeweavers, google, LMGTFY for a start...) Even if it is a relative uneffective captcha, it should at least make spamming more difficult... Wine the mailing list integration, it makes sense to try and get something to strip email addresses (Not sure if the mailing lists archives hide them?) to prevent robots from finding them... (If the official archives is stored in a database (I know phpbb does for the forum), stripping it should be easy (at least for the SQL wizards...)) Gert

Sept. 2, 2010

Re: RFC: Compiling as 16 bit

by Morten Rønne

On 02-09-2010 21:21, Alexandre Julliard wrote: > Morten Rønne<morten.roenne(a)tdcadsl.dk> writes: > > >> I am looking for a way to change windef.h so that it will create the >> correct base types for both 16 and 32 bit compile. >> >> Openwatcom defines the symbol __I86__ while compiling for 16 bit, is >> it acceptable that I use that to create 16 bit types? >> It seems that _MSC_VER will change a few cases of int to long, but far >> from enough. >> Is _MSC_VER intended to be a 16 bit compile flag? >> Or should I use something else more wine like (e.g. __WINE_16BIT_COMPILE). >> >> Also compiling 16 bit give some errors in other include files (after I >> have defined proper sizes for the 16 bit compile) >> ../../../include/winnt.h(3529): Error! E1040: Field width too large >> #ifdef BITFIELDS_BIGENDIAN >> unsigned NameIsString:1; >> unsigned NameOffset:31; >> #else >> unsigned NameOffset:31; >> unsigned NameIsString:1; >> #endif >> As it can be seen the include file uses unsigned directly and not a >> type like DWORD or ULONG that would be a "safe" 32 bit. >> Would it be acceptable to change this and others to a "proper" type >> which I know to be size safe? >> > I don't think it makes sense to invest time into developing a 16-bit > Winelib environment, and we certainly don't want to add 16-bit crap in > the standard Win32 headers. These things should be part of the 16-bit > compiler environment. > > Dear Alexandre After having thought about this again I think you might have misunderstood what I am trying to do. I do not want to compile any part of wine as 16 bit (except the DOS 16 bit tests that I am planing to write). To make sure that I use the same definitions I would of course prefer to use the existing wine include files without having to duplicate every include file that contains something that relates to the 16 bit execution in wine. For example: I would like to test the DOS Program Segment Prefix (aka Program Description Block in windows). That struct is already defined in wine/winbase16.h as PDB16. So I would like to do this in my test program: #include <wine/winbase16.h> PDB16 *psp; In a perfect world this would be enough to have full access to the PDB16 struct in the test program. But alas, the world is not perfect (yet). Since openwatcom uses 16 bit ints the size of DWORD becomes 2 bytes and not 4 bytes as it does with 32 bit ints. Which of course will make the struct wrong in the test program. So I would like to add a few lines to windef.h to handle this: #ifdef __I86__ typedef unsigned int WORD, *PWORD, *LPWORD; typedef long int INT, *PINT, *LPINT; typedef unsigned long UINT, *PUINT; typedef float FLOAT, *PFLOAT; typedef long *LPLONG; typedef unsigned long DWORD, *PDWORD, *LPDWORD; #else /* Current 32 bit defines for the same types */ #endif This only leaves the problem that LONG and a few other bits and pieces are defined elsewhere not using a definition from windef.h. I think that the price of 9 lines of definitions are fine, if that means that every include file can be reused in both 16 and 32 bit test and not having to be duplicated (with all the errors that can cause). If I put some very careful thinking into it I can probably combine it with the current _MSC_VER definitions and boil it down to fewer lines. Again there is no change to anything in the current compile of wine. This will only affect the 16 bit compile of test programs with openwatcom and just mean that the 16 bit test can include existing include files without problems. In the hope that you will consider this again. Best Regards Morten Rønne

Sept. 2, 2010

Re: banning spammer from the forum

by Jeremy Newman

Send me some links to the offending posts in the archive and I will gladly remove them. -N On 08/27/2010 06:04 PM, David Hagood wrote: > On Fri, 2010-08-27 at 08:25 -0500, Rosanne DiMesio wrote: >> Can someone with forum admin rights please ban user Eden1023? I've had to delete multiple spam posts by this user every day for the past few days. >> > It would also be a good idea to purge those spams from the archive: the > goal of them being to create links to the spamvertized sites in order to > raise their page rank in search engines. > > >

Sept. 2, 2010

Re: RFC: test of 16 bit wine (DOS)

by Dan Kegel

On Thu, Sep 2, 2010 at 7:50 PM, Morten Rønne <morten.roenne(a)tdcadsl.dk> wrote: >> Oh, right, win16test's Makefile and probably its test.h are kind of >> simpleminded. >> You probably want to have just one 16 bit test app per dll. >> Hopefully the test cases from win16test will be a useful starting point >> aside from their wimpy build system. > > I would like to avoid the dll part as DOS doesn't know about that and > "simply" run the program directly with tools/run_test. You might have misunderstood. By DLL I just meant the part of Wine that you're testing. In the case of DOS, the tests should probably go in krnl386.exe16/tests. > I will make some tests to see what I can fit into the test system, so it > works the same way other tests do, but as a "standalone" test. Good. That's exactly what I did with win16test. The missing part is integrating into the Wine build sytem. - Dan

Sept. 2, 2010

Re: Console issues in recent git

by Jerome Leclanche

To be more specific, it happens on any and every wine program. J. Leclanche On Thu, Sep 2, 2010 at 8:44 PM, Jerome Leclanche <adys.wh(a)gmail.com> wrote: > It's a GUI. > > > J. Leclanche > > > > On Thu, Sep 2, 2010 at 8:41 PM, Eric Pouech <eric.pouech(a)orange.fr> wrote: >> Le 02/09/2010 03:29, Jerome Leclanche a écrit : >>> >>> Anyone else's terminal emulators really acting up since the last git >>> batch? On konsole (2.5//4.5.00), I'm unable to see what I'm writing if >>> there is a wine process running, until it's killed. This is probably a >>> konsole bug, but still... >>> >>> CC eric. >>> >>> -- >>> J. Leclanche >>> >>> >>> >> >> not really >> is the program you're running a CUI or GUI exec ? >> if it's a CUI, then it's normal as it's supposed to get all your current >> input >> if it's a GUI (without a win32 console), then it's more questionnable >> >> A+ >> >> -- >> Eric Pouech >> "The problem with designing something completely foolproof is to >> underestimate the ingenuity of a complete idiot." (Douglas Adams) >> >> >> >> >

Sept. 2, 2010