wine-devel November 2007

117 participants
275 discussions

by Athel

Hi Rob, i was looking a long time the way to do this. Can you help me to done this?, plis I really need it. If I could understand better the functionality I'll do it for myself. Sorry for my english. Regaards Athel > I was going to wait til tomorrow to test this, but couldnt wait. > This works perfectly for my app and couldnt have came at a better time. > > I just created a simple Win32 dispatcher program for each screen and sent > the window creation messages to the HWNDs from FindWindow instead of the > local app and it creates the dialogs on any screen I want. Joy Joy!!!!! > > It worked out perfectly since the threads that create windows have to send > messages to the main loop for it to create them so that the dialogs dont > from close when the thread exits anyway. > > It is refreshing that after I went through all the battles of getting > multihead display, gcc, and wine running on Solaris that FINALLY something > would work so simply. > > Thanks again to the whole Wine crew that made this possible!!!

16 years, 5 months

Re: widl [1/7]: Output working exception handling macros. [take 3]

by Alexandre Julliard

Dan Hipschman <dsh(a)linux.ucla.edu> writes: > In this revision, I leave setting permissions on page faults to the > unhandled exception filter and simply ignore page faults on execution > access (read access exceptions should be caught since they translate > into bad stub data, but these don't pose a problem anyway). I also > fixed a bug regarding how the mask field of __widl_except_frame was > set. There's no reason to ignore execute access errors, those are bugs too. You are still not filtering the exception properly though, the condition checking has to be done directly in the handler, you can't longjmp back to the code and then re-raise the exception. That's doubly true for the finally handling. This means you have to generate different handlers for the different exception conditions. -- Alexandre Julliard julliard(a)winehq.org

16 years, 5 months

Interesting Behavior of OS X

by Steven Edwards

When tracking down a crash in the kernel32 loader test, Dmitry found a bug in the Mac OS loader when Wine tried to load his dummy PE file. Upon further research I found that the Mac loader seems to have its own undocumented PE loader built in. I did some further testing with a windows binary and got some really interesting results.... #include <stdio.h> #include <dlfcn.h> int main(int argc, char **argv) { void *handle; const char *error; // handle = dlopen("./ldr330e.tmp", RTLD_NOW | RTLD_FIRST ); handle = dlopen("./procexp.exe", RTLD_NOW | RTLD_FIRST ); if (!handle) { fputs (dlerror(), stderr); printf("I guess it didn't load\n"); exit(1); } printf("I guess it loaded\n"); dlclose(handle); } Its trying to load the dlls. I get this output steven-edwardss-imac:temp sedwards$ ./a.out dlopen(./procexp.exe, 258): Library not loaded: WS2_32.dll Referenced from: /Users/sedwards/Library/Application Support/CrossOver/Bottles/winetest/drive_c/windows/temp/procexp.exe Reason: image not foundI guess it didn't load steven-edwardss-imac:temp sedwards$ file procexp.exe procexp.exe: MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit steven-edwardss-imac:temp sedwards$ open . steven-edwardss-imac:temp sedwards$ ./a.out dlopen(./procexp.exe, 258): Library not loaded: MPR.dll Referenced from: /Users/sedwards/Library/Application Support/CrossOver/Bottles/winetest/drive_c/windows/temp/procexp.exe Reason: image not foundI guess it didn't load steven-edwardss-imac:temp sedwards$ ./a.out dlopen(./procexp.exe, 258): Library not loaded: MPR.dll So this leads to the question. Whats going on? Is this a hold over from EFI which is PE by default? Why would the OS need to load the EFI files? Maybe just for easy of development and testing? Or is something else going on? Is Apple going to be adding a win32 compatibility layer to OS X? Is having a native PE loader of any use to us? Thanks Steven -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

16 years, 5 months

re: wininet [2/2]: Fix error checking for FtpGetCurrentDirectoryW

by Dan Kegel

Hi Zac, you wrote * Fixed errors in error checking in FtpGetCurrentDirectoryW in wininet/ftp.c It's probably a good idea to explain what real-world problem this fixes. One good way to do that is to submit a test first that fails, with todo(wine) around the failing part, and then submit a second patch which fixes the problem and removes the todo(wine) from the test. - if (NULL == lpwfs || WH_HFTPSESSION != lpwfs->hdr.htype) + if ( lpwfs == NULL || WH_HFTPSESSION != lpwfs->hdr.htype ) Why did you make this change? It doesn't fix anything, and it removes an old coder's anti-typo-measure of putting the const on the left hand of an equality test. Please remove this hunk. - if (lpwfs->download_in_progress != NULL) + if ( lpszCurrentDirectory == NULL || *lpdwCurrentDirectory == NULL ) You switched to tabs, tsk. Also, you changed whitespace style. Always try to match the file's existing style. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

16 years, 5 months

re: wininet [1/2]: Add test for FtpGetCurrentDirectoryA

by Dan Kegel

Nice to see you contributing tests! Three comments: 1. you seem to have ragged indentation. Did you remember to remove all tabs? (Hmm. Our doc on the tab issue is a bit weak: neither http://winehq.org/site/sending_patches http://winehq.org/site/docs/winedev-guide/style-notes really capture the current anti-tab mood.) 2. You have a nice testDir variable, but then you hard-code "pub" somewhere. Use the variable everywhere. 3. Did you make sure the new tests pass on Windows? -- Wine for Windows ISVs: http://kegel.com/wine/isv

16 years, 5 months

Adding Bugzilla keyword for Copy-protection/Debugger issues

by Ben Hodgetts (Enverex)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just a thought but it may be a good idea to add a keyword to Bugzilla for issues related to debuggers or copy-protection, that would help group them all together as at the moment there seem to be many bugs related to breakages from obscure debugger protections or things like GameGuard. It's much cleaner than the hated meta bug idea and is easier to implement. Just a thought. Ben H. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTrfQuqCUopk11kIRAhDnAJ4iGkr6bUk1/FPUFrrdzlsnqC5dDwCfd2r5 WDylDKMPprC22RtEwYG01o4= =fLJB -----END PGP SIGNATURE-----

16 years, 5 months

Re: [server] set serial port fd back to blocking if necessary

by Alexandre Julliard

"Damjan Jovanovic" <damjan.jov(a)gmail.com> writes: > This fixes a regression caused by commit > f85437c57fb44d511db97edbaa5b1f8abfe75fd3 (bug 9356) where serial ports > break because they are not made blocking. > > Changelog: > * Set serial port fd back to blocking if necessary This will break timeout handling. There shouldn't be any reason for the fd to be blocking, we should handle EAGAIN properly. -- Alexandre Julliard julliard(a)winehq.org

16 years, 5 months

Re: [PATCH 1/3] advpack/tests: Rename the wrappers around HeapAlloc() &Co to use the new standard naming.

by James Hawkins

On Nov 28, 2007 3:39 PM, Michael Stefaniuc <mstefani(a)redhat.de> wrote: > Alexandre, > > i'm unsure about this patch series. Yes this are simple wrappers around > HeapAlloc() that are the same as the "standard" wrappers used in Wine. > But they are used only as callbacks aka different usage. > I don't think this particular series is beneficial. Your script won't be able to use these names because they're not called directly. -- James Hawkins

16 years, 5 months

d3dx9__xx dlls

by David.Adam＠math.cnrs.fr

Following Alexandre (and I agree with him :D ), one only needs to export the functions of d3dx9_36 (the latest one) to the older d3dx9_xx dlls. So, we just just need to implement the functions in the d3dx9_36 dll repertory. No wine_d3dx9 is useful. David

16 years, 5 months

Re: [try2 1/1] msi/tests: automation: Fix pointer check before calling lstrcpyW.

by Alexandre Julliard

Misha Koshelev <mk144210(a)bcm.edu> writes: > The previous patch was last week I think. This fixes a Valgrind error in the test. This is > correct as vtResult is just hte _expected_ return type, and this way we check the actual return type > (new this version) and then the validity of the pointer (same as old patch) before calling lstrcpyW > so we don't pass NULL to lstrcpyW. It seems to me what you really want to do is check that the call succeeded, instead of relying on the variant being cleared on error. -- Alexandre Julliard julliard(a)winehq.org

16 years, 5 months

← Newer
1
2
3
4
5
6
7
8
...
28
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 November 2007