wine-devel February 2009

wine-devel@winehq.org

143 participants
298 discussions

Re: msctf/tests: Don't import uuid library cause it could break crosstest
by Paul Vriens 19 Feb '09

19 Feb '09

Nikolay Sivov wrote: > Changelog: > - Don't import uuid library cause it could break crosstest > >>From 26890998dc20bd31c2d23b8b59dfaf664ca98dc0 Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <bunglehead(a)gmail.com> > Date: Thu, 19 Feb 2009 10:20:32 -0500 > Subject: Don't import uuid library cause it could break crosstest > > --- > dlls/msctf/tests/Makefile.in | 2 +- > dlls/msctf/tests/inputprocessor.c | 1 + > 2 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/msctf/tests/Makefile.in b/dlls/msctf/tests/Makefile.in > index 669f5a1..0d7aba8 100644 > --- a/dlls/msctf/tests/Makefile.in > +++ b/dlls/msctf/tests/Makefile.in > @@ -3,7 +3,7 @@ TOPOBJDIR = ../../.. > SRCDIR = @srcdir@ > VPATH = @srcdir@ > TESTDLL = msctf.dll > -IMPORTS = uuid ole32 user32 kernel32 > +IMPORTS = ole32 user32 kernel32 > > CTESTS = \ > inputprocessor.c > diff --git a/dlls/msctf/tests/inputprocessor.c b/dlls/msctf/tests/inputprocessor.c > index 200a0d4..2e71eec 100644 > --- a/dlls/msctf/tests/inputprocessor.c > +++ b/dlls/msctf/tests/inputprocessor.c > @@ -33,6 +33,7 @@ static ITfInputProcessorProfiles* g_ipp; > static LANGID gLangid; > > DEFINE_GUID(CLSID_FakeService, 0xEDE1A7AD,0x66DE,0x47E0,0xB6,0x20,0x3E,0x92,0xF8,0x24,0x6B,0xF3); > +DEFINE_GUID(CLSID_TF_InputProcessorProfiles, 0x33c53a50,0xf456,0x4884,0xb0,0x49,0x85,0xfd,0x64,0x3e,0xcf,0xed); > > static HRESULT initialize(void) > { Hi Already fixed in Git: http://source.winehq.org/git/wine.git/?a=commit;h=cd656fa7f68bc86f78be21c67… -- Cheers, Paul.

1 0

Re: msctf crosstest build failed
by Nicolas Le Cam 19 Feb '09

19 Feb '09

2009/2/19 Nikolay Sivov <bunglehead(a)gmail.com>: > Nicolas Le Cam wrote: >> >> 2009/2/18 Nikolay Sivov <bunglehead(a)gmail.com>: >> >>> >>> Building today crosstests I've got: >>> >>> i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include >>> -g -O2 -o inputprocessor.cross.o inputprocessor.c >>> i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include >>> -g -O2 -o testlist.cross.o testlist.c >>> i586-mingw32msvc-gcc inputprocessor.cross.o testlist.cross.o -o >>> msctf_crosstest.exe -L../../../dlls -L../../../dlls/uuid >>> -L../../../dlls/ole32 -L../../../dlls/user32 -L../../../dlls/kernel32 >>> -luuid -lole32 -luser32 -lkernel32 >>> inputprocessor.cross.o: In function `initialize': >>> /home/mrlarch/wine-git/dlls/msctf/tests/inputprocessor.c:41: undefined >>> reference to `_CLSID_TF_InputProcessorProfiles' >>> collect2: ld returned 1 exit status >>> make[2]: *** [msctf_crosstest.exe] Error 1 >>> make[2]: Leaving directory `/home/mrlarch/wine-git/dlls/msctf/tests' >>> make[1]: *** [msctf/tests/__crosstest__] Error 2 >>> make[1]: Leaving directory `/home/mrlarch/wine-git/dlls' >>> make: *** [dlls/__crosstest__] Error 2 >>> >>> This outputs after: >>> make clean >>> ./configure >>> make depend && make >>> make crosstest >>> >>> What seems to be a problem? >>> >>> >>> >>> >> >> Same here. Can't find a solution. >> Perhaps it's because libuuid exports the CLSID as >> CLSID_TF_InputProcessorProfiles instead of >> _CLSID_TF_InputProcessorProfiles but I don't know how to fix. >> > > It's normal, is a kind of naming convention, don't know how to call it > right, but it's ok. >> >> Does building it with winegcc instead of ar / ranlib could fix the problem >> ? >> > > Native test builds without any problem. What do you mean? > As I checked uuid isn't imported anywhere else in test suite, inline guid > definitions used instead. > So if nobody knows why this happens I propose to patch msctf/tests not to > use uuid. > Now I'm setting up a system with rather fresh Lenny, so you could send this > patch. > > Just found that Alexandre committed something related to that last year. It seems to be a problem with MingW, see [1]. I will send a fix this evening. [1] http://source.winehq.org/git/wine.git/?a=commit;h=79c64acc7b5f9f9de07592fec…

2 1

msctf crosstest build failed
by Nikolay Sivov 19 Feb '09

19 Feb '09

Building today crosstests I've got: i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include -g -O2 -o inputprocessor.cross.o inputprocessor.c i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include -g -O2 -o testlist.cross.o testlist.c i586-mingw32msvc-gcc inputprocessor.cross.o testlist.cross.o -o msctf_crosstest.exe -L../../../dlls -L../../../dlls/uuid -L../../../dlls/ole32 -L../../../dlls/user32 -L../../../dlls/kernel32 -luuid -lole32 -luser32 -lkernel32 inputprocessor.cross.o: In function `initialize': /home/mrlarch/wine-git/dlls/msctf/tests/inputprocessor.c:41: undefined reference to `_CLSID_TF_InputProcessorProfiles' collect2: ld returned 1 exit status make[2]: *** [msctf_crosstest.exe] Error 1 make[2]: Leaving directory `/home/mrlarch/wine-git/dlls/msctf/tests' make[1]: *** [msctf/tests/__crosstest__] Error 2 make[1]: Leaving directory `/home/mrlarch/wine-git/dlls' make: *** [dlls/__crosstest__] Error 2 This outputs after: make clean ./configure make depend && make make crosstest What seems to be a problem?

3 4

Need help on couple of patches
by Igor Tarasov 19 Feb '09

19 Feb '09

Hello! I've written 2 patches, and I need advice on both of them. First one is here: http://www.winehq.org/pipermail/wine-patches/2009-February/069463.html It's a single-line patch that adds forwarding notification that was omitted in wine code. This fix looks pretty simple, but it included lots of reading/testing/debugging, and here is what I came with. And as I told there it fixes one wine bugzilla bug. But as I see, it was not comitted, so I am asking for advice: what could I do in order to make it go through? Another patch is here: http://bugs.winehq.org/show_bug.cgi?id=12701 The patch adresses 3 problems that all together fix that bug. My question there was if I should send it in one patch or in several. But it seems that no one have noticed that post. Any help and advice is appreciated. Thanks.

5 10

Re: [8/9] setupapi: implement SetupPromptForDiskA by wrapping around W version
by Juan Lang 19 Feb '09

19 Feb '09

Hi Ricardo, + DialogTitleW = MultiByteToUnicode(DialogTitle, CP_UTF8); You should be using CP_ACP here, not CP_UTF8. Same applies to remaining character conversions. In fact, you could use strdupAtoW instead. --Juan

2 1

Wine & viruses
by Martin Hinner 19 Feb '09

19 Feb '09

Hi, I will start one more hot discussion. Sorry if it was discussed earlier, I am not regular reader of this mailing-list. I tried to search google, found several discussions, but no real result: http://www.linux.com/feature/42031 http://www.vnunet.com/vnunet/news/2116150/linux-experts-wine-virus https://bugs.launchpad.net/ubuntu/+source/wine/+bug/256880 wine-devel mailing list google results The problem is that some (almost all?) distributions simply execute .exe file when you click on it. I was amazed when testing JTAGTest on Linux! This is in my opinion quite big issue as ordinary users do not have problem clicking on "New folder.exe" on their flashdisk etc. It's good that wine is so compatible that it runs even viruses, but I think there should be some (optional) protection. The biggest problem seem to be removable media, in many distributions mounted under /mnt or /media. Please think about this twice before writing "problem is in Microsoft not in Wine", "it's not a bug but feature", etc. It's too childish IMO. - What about creating a configurable list of directories, where wine would first ask if you really want to execute the program? It would be up to distribution what is set-up by default. - It's long time I have been interested in viruses, but I think that 90% of most common virus infected/trojan .exe files can be pretty easily identified. Almost every modern virus is trying to connect to the internet either by opening socket or using few standard DLL functions. What about adding some checks to Wine that would check the calling function code sample against some small database to see if this is a virus and ask user? Or adding some "API" functions to allow someone to write such program? I have done quite a lot of work with PE loading and code modification and I think it could be moved to level when it works without crashing anything. I understand, that none of this is system solution. But are anti-viruses system solution? They solve real world problem. Regarding API I have mentioned above I mean some hookdll() function that would re-direct GetProcAddress() or PE loader for defined functions, i.e.: http://www.codeguru.com/cpp/w-p/dll/hooking/article.php/c3639 http://www.codeguru.com/cpp/w-p/dll/hooking/article.php/c127 Obviously this would have to be global for wine (libwine.so?), not as a PE exported API function. Pre-loaded "antivirus" would be able to hook Winsock functions + some other important stuff and then check if the binary code is not on the list. Martin

9 13

Re: [1/9] setupapi: add header information for SetupPromptForDisk
by Juan Lang 19 Feb '09

19 Feb '09

Hi Ricardo, > dlls/setupapi/setupapi_private.h | 11 +++++++++++ > include/setupapi.h | 14 +++++++++----- I'd suggest you have the changes to setupapi.h as one patch on their own. The changes to setupapi_private.h can be combined with the changes to the .rc file (patch 2 in your series), along with your patch to create the new dialog.c file (patch 3 in your series), and your patch to create a do-nothing dialog (patch 4 in your series.) In this way, each patch has a single functional change. If you do it as I suggest, patch 1 will change the public header file. Patch 2 will introduce a new dialog. The remaning patches seem split appropriately, so you'd end up with a 7 patch series. --Juan

1 0

Re: Wine64 - msvcrt dll test fix
by Ricardo Filipe 19 Feb '09

19 Feb '09

this was commited already today. :) http://source.winehq.org/git/wine.git/?a=shortlog 2009/2/18 Juan M. Navarro <juan.m.navarro(a)gmail.com> > Resending as plain text. > > Thanks, > Juan > > On Tue, Feb 17, 2009 at 12:19 PM, Juan M. Navarro > <juan.m.navarro(a)gmail.com> wrote: > > Hello all! > > > > This is my first patch ever, and first open source contribution ever. > > > > The strlen function returns a size_t that represents an unsigned int in > > 32-bit environments, and an unsigned long in 64-bit environments. The > strlen > > function call has been changed to an lstrlen function call, which always > > returns an integer. > > > > I am a grad student at UCLA that has just started working on porting Wine > to > > 64-bit environments. > > > > I attest to not having seen any Microsoft source, or dissasembling > > Microsoft's DLL's. > > > > Thanks, > > > > Juan > > > >

1 0

Re: Status of USB driver support?
by emiliano esposito 18 Feb '09

18 Feb '09

Alexander Morozov wrote: >> If that USB Key is not of a supportable kind, then I apologize for >> asking. >> > > I think you should try. > Thanks. I tried this way: git clone git://source.winehq.org/git/wine.git ~/wine-git git-am 0001... git-am 0002... ./tools/wineinstall When launching a Wine application, I get some errors, I think this is the important one: err:winedevice:ServiceMain driver L"Usbhub" failed to load I have installed the Key driver but not yet added the registry keys. Should I do that or something else first? Thanks.

1 0

Status of USB driver support?
by Dan Kegel 18 Feb '09

18 Feb '09

Is http://wiki.winehq.org/USB up to date? I could have sworn that Alexander Morozov had submitted a new version of his patch, but I can't find it.

5 7

← Newer
1
...
6
7
8
9
10
11
12
...
30
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel February 2009