November 2007 - Wine-Devel - list.winehq.org

Re: shell32: symlink user's profile shell folders to xdg well known directories [2/2] (try 3)

by Alexandre Julliard

"Dan Kegel" <dank(a)kegel.com> writes: > I feel like a broken record, but: > some apps don't like following symlinks, and the > native Windows way to configure what the "My Foo" > folders point to is called shell folder redirection; > These are documented at > http://support.microsoft.com/kb/242557 > among other places, and I think Wine supports these > registry settings. Is there any reason we don't want > to use these instead of symlinks? We want the paths to remain valid even if the drive configuration is changed, so they have to point somewhere inside the C: drive. -- Alexandre Julliard julliard(a)winehq.org

Nov. 29, 2007

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

Nov. 29, 2007

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

Nov. 29, 2007

re: shell32: symlink user's profile shell folders to xdg well known directories [2/2] (try 3)

by Dan Kegel

I feel like a broken record, but: some apps don't like following symlinks, and the native Windows way to configure what the "My Foo" folders point to is called shell folder redirection; These are documented at http://support.microsoft.com/kb/242557 among other places, and I think Wine supports these registry settings. Is there any reason we don't want to use these instead of symlinks? - Dan

Nov. 29, 2007

Re: xdg_user_dirs patches

by Alexandre Julliard

"Lei Zhang" <thestig(a)google.com> writes: > I was not sure if was alright to mix code with different licenses in > the same file. I looked around and found that > include/wine/wined3d_gl.h has both LGPL Wine code as well as MIT > licensed code from the Mesa project. Based on that, I guess it's ok to > do, so I will send out another patch. It's OK to do, but I don't think you want to copy the code as is, you should write your own version that parses the file only once and handles variables as they are found. Also these variables should take priority over the default heuristics, and you most likely want to handle the desktop dir the same way. -- Alexandre Julliard julliard(a)winehq.org

Nov. 28, 2007

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

by Michael Stefaniuc

James Hawkins wrote: > On Nov 28, 2007 3:39 PM, Michael Stefaniuc <mstefani(a)redhat.de> wrote: >> 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. I know. But i had written the patches already but before wiping them from my tree i thought to send them in for documentation purpose. Btw. the unfree-wine.pl has mem_alloc() in there because of the malloc() wrapper in the server that happens to have the same name. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 -------------------------------------------------------------------- Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart Handelsregister: Amtsgericht Stuttgart HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich

Nov. 28, 2007

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

Nov. 28, 2007

Re: d3dx9__xx dlls

by Michael Stefaniuc

Vijay Kiran Kamuju wrote: > On Nov 28, 2007 12:34 PM, Michael Stefaniuc <mstefani(a)redhat.com> wrote: >> Maarten Lankhorst wrote: >>> Stefan Dösinger schreef: >>>> What do we do if there's a d3dx9_37.dll next month? >>>> >>> One thing that comes to mind is: git-mv d3dx9_36 d3dx9_37 and create a >>> forward dll for the old one. >> Renames are "cheap" in git and we do not loose the history. > I also think that rename is not a good idea. Heh. I didn't say that i don't like renames. I said renames are a workable solution: read there's no technical reason why to not use them. > I would like propose a new idea, why dont we have different spec files > inside wine_d3dx for all different versions of dlls. > Its something like we have done it in the ole32. > But, it requires some makefile/configure cruft. There's no need to name that wine_d3dx. Nothing stops us to name it d3d9x and have all the other versions generated inside that. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111

Nov. 28, 2007

Re: xdg_user_dirs patches

by Lei Zhang

On Nov 26, 2007 4:49 PM, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > Hi Lei, > > I think a new file for user dir look up in the shell32 is of no use. > Rather than we can add it to the xdg.c and xdg.h, as it contains the > generic xdg code for shell32. > Its like having all xdg specific code at one place. > This is my personal opinion about those patches. > > Thanks, > VJ > > > I was not sure if was alright to mix code with different licenses in the same file. I looked around and found that include/wine/wined3d_gl.h has both LGPL Wine code as well as MIT licensed code from the Mesa project. Based on that, I guess it's ok to do, so I will send out another patch. - Lei

Nov. 28, 2007

Re: d3dx9__xx dlls

by Vijay Kiran Kamuju

On Nov 28, 2007 12:34 PM, Michael Stefaniuc <mstefani(a)redhat.com> wrote: > Maarten Lankhorst wrote: > > Stefan Dösinger schreef: > >> What do we do if there's a d3dx9_37.dll next month? > >> > > One thing that comes to mind is: git-mv d3dx9_36 d3dx9_37 and create a > > forward dll for the old one. > Renames are "cheap" in git and we do not loose the history. I also think that rename is not a good idea. I would like propose a new idea, why dont we have different spec files inside wine_d3dx for all different versions of dlls. Its something like we have done it in the ole32. But, it requires some makefile/configure cruft. > > bye > michael > -- > Michael Stefaniuc Tel.: +49-711-96437-199 > Consulting Communications Engineer Fax.: +49-711-96437-111 > -------------------------------------------------------------------- > Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart > Handelsregister: Amtsgericht Stuttgart HRB 153243 > Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, > Werner Knoblich > > >

Nov. 28, 2007