January 2008 - Wine-devel - list.winehq.org

Re: your winhttp work
by Hans Leidekker 28 Jan '08

28 Jan '08

On Sunday 27 January 2008 06:42:45 EA Durbin wrote: [ I decided to CC wine-devel since you're the second person to ask ] > You had completed some work on winhttp and provided a snapshot in bug 9200. > Has this been sent to wine-patches yet? I was going to tinker with it a bit > to see if I could get an app working and wondered if you had anything more > up to date or if this had been merged into git yet? If you've already got > a solution I don't want to reinvent the wheel. Here's a rediffed version of my unfinished winhttp patch. I wrote it primarily to explore the option of implementing winhttp on top of wininet. Basically we are faced with a choice between this option, which requires a Wine-only extension to wininet to implement winhttp style callbacks, and duplicating wininet code. I think layering can be done in a relatively clean way by making wininet handle the superset of wininet and winhttp callbacks and adding callback filtering as required by winhttp. Old wininet behavior can then be obtained by an implicit filter on the wininet subset of callbacks. If time permits I'll write a comprehensive test suite for winhttp which should help us make an informed decision. -Hans

1 2

Re: start.exe: Handle the process title argument
by Dmitry Timoshkov 28 Jan '08

28 Jan '08

"Alexander Nicolaysen Sørnes" <alex(a)thehandofagony.com> wrote: > + NOTE: This will only work when run from Wine's cmd, but that's ok as start is a builtin > + shell command on NT */ What's the purpose of the comment above? > + if(argc > 1 && (vi.dwMajorVersion >= 5 || (vi.dwMajorVersion == 4 && vi.dwPlatformId == 2))) Unless there is an app which would break because of the title set there is no need to check the version. > + { > + int cmdcount; > + WCHAR* cmdline = GetCommandLineW(); > + WCHAR** cmdargs = CommandLineToArgvW(cmdline, &cmdcount); > + WCHAR* pos = cmdline; wmain() already has arc/argv pair of parameters, why do you need to parse command line again? > + > + pos += lstrlenW(cmdargs[0]); > + > + while(*pos == ' ') > + pos++; > + > + if(*pos == '"') > + { > + /* FIXME: Set the process title */ > + i++; > + } > + LocalFree(cmdargs); > + } I assume that you've added LocalFree as MSDN suggests, but CommandLineToArgvW in Wine uses GlobalAlloc, perhaps you could fix that? -- Dmitry.

2 1

Sorry about the extraordinary amount of wine-bugs spam
by Dan Kegel 28 Jan '08

28 Jan '08

I've been as annoyed as anybody at the huge churn on wine-bugs lately, it makes it hard to actually read, and the mailing list archive can't really cope. But there seems to be no way around it, so I decided to get a bunch more out of the way in one fell (and I do mean fell) swoop. In particular, I closed over a thousand old RESOLVED FIXED, RESOLVED ABANDONED, RESOLVED WORKSFORME, and RESOLVED INVALID bugs tonight. You can see the effect here: http://bugs.winehq.org/reports.cgi?product=Wine&datasets=RESOLVED%3A&datase… The only real benefit of this is fixed bugs will show up with strikethrough now when referenced in bugzilla, which is actually kind of nice. I'd like to get all the wine-bugs churn out of the way during January, if possible. For reference, the rule of thumb for closing RESOLVED bugs is: FIXED and WORKSFORME: can be closed after two weeks (i.e. after release) ABANDONED: can be closed after three months INVALID: can be closed immediately, but if it's less than a couple months old, check to make sure somebody wasn't just being cranky - Dan

1 0

question for dumps
by Juan Carlos Montes 28 Jan '08

28 Jan '08

Hi all, I need dump the data using the debug log. trace:winsock:WSASendTo socket 00f8, wsabuf 0x34e1e0, nbufs 1, flags 0, to (nil), tolen 0, ovl (nil), func (nil) if have this one, can i dump the data in 0x34e1e0 with another option in debug, or i need change the source? thanks a lot, -- _______________________________________________________________________________ Juan Carlos Montes Senra INTECO-CERT Instituto Nacional de TecnologÃas de la ComunicaciÃ³n email: juancarlos.montes(a)inteco.es | jcmontes(a)cert.inteco.es Tlf. 0034 987 877 189 - ext. 532 _______________________________________________________________________________

4 8

Re: gitignore: ignore files generated by the Visual C++ compiler.
by Dmitry Timoshkov 28 Jan '08

28 Jan '08

"Reece Dunn" <msclrhd(a)googlemail.com> wrote: > This patch ignores any files generated by the Visual C++ compiler to > make it easier to generate patches when using the VCExpress family of > compilers on Windows. There is no point in that, patches should be generated after testing in Wine under a supported platform. -- Dmitry.

6 6

Vacation
by Alexandre Julliard 27 Jan '08

27 Jan '08

Hi folks, Once again you'll have to live without commits for a while, I'm off skiing for a week... -- Alexandre Julliard julliard(a)winehq.org

3 2

RE : [Fwd: d3dx8: Implement D3DXCreateTextureFromFile]
by paulo lesgaz 27 Jan '08

27 Jan '08

The real file is d3dx8tex.h and not d3dx8texture.h. You need to use the same name as windows uses. David "Luis C. Busquets Pérez" <luis.busquets(a)ilidium.com> a écrit : I have created a /dlls/d3dx8/texture.c file where to put all functions related to textures and d3dx8. I have included D3DXIMAGE_FILEFORMAT in the patch because it is referred by D3DXIMAGE_FILEFORMAT which is referred in the function. If not included, it would not compile. They both are now in /include/d3dx8.h whci I think is the appropiate file. Do you propose to put them elsewhere? Do you think I am missing anything or is it ok? --------------------------------- Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail

1 0

Re: Implement D3DXCreateTextureFromFile
by Dmitry Timoshkov 27 Jan '08

27 Jan '08

"Luis C. Busquets Pérez" <luis.busquets(a)ilidium.com> wrote: > diff --git a/dlls/d3dx8/d3dx8_main.c b/dlls/d3dx8/d3dx8_main.c > index c24aedc..931e6c1 100644 > --- a/dlls/d3dx8/d3dx8_main.c > +++ b/dlls/d3dx8/d3dx8_main.c > @@ -32,6 +32,30 @@ > #include "wine/unicode.h" > #include "d3dx8_private.h" > > +typedef enum D3DXIMAGE_FILEFORMAT > +{ > + D3DXIFF_BMP = 0, > + D3DXIFF_JPG = 1, > + D3DXIFF_TGA = 2, > + D3DXIFF_PNG = 3, > + D3DXIFF_DDS = 4, > + D3DXIFF_PPM = 5, > + D3DXIFF_DIB = 6, > + D3DXIFF_HDR = 7, > + D3DXIFF_PFM = 8, > + D3DXIFF_FORCE_DWORD = 0x7fffffff, > +} D3DXIMAGE_FILEFORMAT, *LPD3DXIMAGE_FILEFORMAT; D3DXIMAGE_FILEFORMAT s inot used in your patch, so it either should be a separate patch, or removed. > +typedef struct _D3DXIMAGE_INFO { > + UINT Width; > + UINT Height; > + UINT Depth; > + UINT MipLevels; > + D3DFORMAT Format; > + D3DRESOURCETYPE ResourceType; > + D3DXIMAGE_FILEFORMAT ImageFileFormat; > +} D3DXIMAGE_INFO; If D3DXIMAGE_INFO is used in public API definitions it should be placed in an appropriate SDK header. -- Dmitry.

2 1

RegOverridePredefKey stub
by Jens Nestler 27 Jan '08

27 Jan '08

Hello all, I'm a Windows software developer and I'm trying to execute an application under the wine environment. Now I have a problem introduced with wine 0.9.49. I use the function RegOverridePredefKey from the advapi32.dll. In wine 0.9.49 a stub entry for this function was created, but the implementation is missing. To hold my code running, I need any implememtation for this function. Please apply the attached patch for a stub implementation. Thank you Jens

4 4

d3dx: A few last questions...
by tony.wasserka＠freenet.de 27 Jan '08

27 Jan '08

Hi, So far I have pretty much completed the d3dx9_24 dll. However, while writing the spec files I faced a few problems which I'd like to have solved befor submitting the patch: 1. With the d3dx9_31 dll, microsoft removed three functions from the SDK. I'm curious what to do with them. Should I stub them at the first or last dll they're used in? Also, How should I handle the forwarding thing then? I'm importing d3dx9_36 in each dll, but need to import the dll containing the three functions, too (I'm just asking to make sure there won't be any collisions or conflicts or something). By the way, the three functions are D3DXCpuOptimizations, GetTargetDescByName and GetTargetDescByVersion. 2. Another problem is, that many functions changed in there argument list from one version to the next one. For example http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c… Says, that D3DXCreateFont changed the type of the D3DXFONT_DESC member Height from UINT to INT. I think (but don't know, so I ask) that this could lead to a misbehavior in some programs, as a UINT has a significant difference in the bit structure to INT. Also, the Angle parameter in D3DXSHRotateZ was changed from const FLOAT to FLOAT, which COULD also lead to problems. 3. Also, the MSDN seems to lack the info about D3DXGetTargetDescByName and D3DXGetTargetDescByVersion. I'd be really gradeful if someone who has an old version of the DXSDK installed could take a look into the headers and tell me the argument list. 4. And just to make sure, I attached the d3dx9_24 specfile. Everything but the argument types should be okay I think, but please tell me if you find any other problems with it, like typos in function names or something about the forwarding. Also, the two D3DXGetTargetDescByName/Version functions don't have argument lists yet as I couldn't find resources about them. That's it at the moment, I'll reply later to this topic if there appear new problems. Thanks for any answers, best regards Tony Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i…

1 0