re: Add d3drmdef.h header - try 2
Vijay wrote: Add minimalistic d3drmdef.h But why? None of the code in wine currently needs it. Maybe you should submit it together with the first bit of code that needs it. -- Wine for Windows ISVs: http://kegel.com/wine/isv
const cleanup round 1(commentary on what I found)
Some of this was included in the patch submission. Some of it I had questions about. spawn.c : warnings may or may not be harmless depending on if esecvp attempts to modify the results. Specs indicate it doesn't, but the function typing doesn't indicate so(the difference is 'const char * const argv[]' and 'char *const argv[]') libs/wine/string.c: strstrW - returns the location where sub was found in str. I believe returning a non-const value is what is expected. Should this be changed to a non-const parameter, or just leave the warning as is? tools/winedump/pdb.c: pdb_exit [line 149,153,155] - freeing of const variable. Is this ok? I could imagine it *could* cause problems if what we are freeing isn't in readable/writeable memory. pdb_dump_symbols [line 293,403,409] - same as pdb_exit. pdb_dump_types [line 462] - ditto pdb_jg_dump line[514] - ditto pdb_ds_dump line[643] - ditto tools/winedump/search.c: get_type [line 305, 329] - freeing of const variable again. [line 314, 335] - both cases, set return_text to type_str. Either parsed_symbol's return_text needs to be constified, proto should be unconstified, or leave it in place as a necessary cast. Any comments on the above spots? what of these are necessary casts? what of these can/should be corrected, and what needs to be done to correct them? **patches submitted to wine-patches** the following were straight forward patches that shouldn't modify the flow of the program beyond fixing the warnings. libs/wine/string.c: strtolW and strtoulW - constify the endptr value. This is just an output value to indicate where in the array we stoped processing. Change causes this to be the same type as the first value. Reduces number of cast-qual warnings by 6. tools/winedump/lnk.c: dump_pidl [line 176] - switched to const. Value is never modified in the function. Removes a cast-qual warning. tools/winedump/symbol.c: symbol_clean_string - this function is modifying the string. This should most definitely *not* be a const parameter. It's not even logically const(as a comment tried to claim) as the the intent of the function is to make the type string Wine-friendly. That requires modifications to that string, and to the variable. Removes a cast-qual warning. Comments? questions? Current number of cast-qual warnings fixed: 8. Number deemed necessary: 0(you guys need to help me decide what of these need to remain) Number looked at: 24. Estimated number remaining: 521.
Re: Set D3DCAPS2_DYNAMICTEXTURES flag
On 13/03/07, Mirek [EMAIL PROTECTED] wrote: Shouldn't we use WINED3DCAPS2_DYNAMICTEXTURES rather than D3DCAPS2_DYNAMICTEXTURES ? Yes, this won't compile like this.
Re: Add d3drmdef.h header - try 2
On Tue, 13 Mar 2007, Vijay Kiran Kamuju wrote: Changelog --- Add minimalistic d3drmdef.h extern LPD3DVECTOR D3DRMAPI D3DRMVectorAdd(LPD3DVECTOR, LPD3DVECTOR, LPD3DVECTOR); Two nitpicks: Wine's headers usually don't specify extern (it's implicit). If there's a large list of functions it can also be nice to sort them in alphabetical order as other forms of grouping tend to break down after a time. But this is not a hard and fast rules and it is not always followed. -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS
Re: Add d3drmdef.h header - try 2
Hi, Please ignore the this one. I am sending a new one. I wrongly named the header file, effects of late night coding bye, VJ On 3/13/07, Francois Gouget [EMAIL PROTECTED] wrote: On Tue, 13 Mar 2007, Vijay Kiran Kamuju wrote: Changelog --- Add minimalistic d3drmdef.h extern LPD3DVECTOR D3DRMAPI D3DRMVectorAdd(LPD3DVECTOR, LPD3DVECTOR, LPD3DVECTOR); Two nitpicks: Wine's headers usually don't specify extern (it's implicit). If there's a large list of functions it can also be nice to sort them in alphabetical order as other forms of grouping tend to break down after a time. But this is not a hard and fast rules and it is not always followed. -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS
d3drm test implementation need comments and review
Hi, I have implemented some d3drm functions and made some changes. Original implementation is by David Adam. Currently I dont have a wine repository to test the patch. Before applying the patch please create the dlls/d3drm/tests directory Please send me you comments, regarding this. If there are any compilation/execution errors, please notify me. I will correct them (I dont have access to linux m/c currently) Thanks, VJ d3drm.diff Description: Binary data
Re: [11/19] cmd.exe: Add dir /Q support
Ann Jason Edmeades [EMAIL PROTECTED] writes: +secBuffer = (LPBYTE) malloc(sizeNeeded * sizeof(BYTE)); +if(!secBuffer) return; Please don't use malloc in Wine. -- Alexandre Julliard [EMAIL PROTECTED]
Re: winedbg: Support longer thread names
Erich Hoover a écrit : I am not very familiar with the winedbg code and do not see any easy (ie, non-hackish) way to get the length of the string in order to properly allocate the name size. I could read back a large buffer and use the string resulting from that to determine how large of a name to allocate, but that seems slightly hackish. If you have a suggestion then I'm all ears. not really, my point was not to allocate a large buffer for every thread... then reading the thread name requires either that you grow the buffer while reading small chunks (that would be the less expensive solution) A+ Erich Hoover [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] On 3/11/07, *Eric Pouech* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Erich Hoover a écrit : Real Name: Erich Hoover Description: The thread name length in winedbg is currently restricted to 9 characters, this is not nearly long enough for debugging threads in the Supreme Commander demo and results in character corruption on the terminal. Since this particular application names one of the threads with the map path (Map loader /maps/scmp_019/scmp_019.scmap), a significant increase in the number of characters is necessary. This patch ups the allowed thread name length to 100 characters and null-terminates the string in case an application exceeds that threshold value. Changelog: winedbg: Support longer thread names in that case, it would be better to dynamically allocate the string (and to create it by default at 5 bytes for the %04x value) furthermore, you need to change the comment in debugger.h in THREADNAME_INFO structure about the name's length, as it seems VC7 removed the restriction to 8 characters that existed in VC6 A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
My plans for SOC
For the summer of code I'm planning to improve the dsound code and alsa code, to make alsa finally better then OSS, in a way that has a will get accepted into the wine tree, for that I'm thinking of improving on the following fronts: Winealsa: - Add mixer device and aux controls - Implement dsound capture - Seperate the initialisation of the directsound code from the waveout code, to allow creation of multiple dmix devices. - Try to configure alsa to allow arbitrarily big buffers, working around the alsa problem that only up to a certain amount can be allocated for buffers, certain programs (for example winamp) may require more. - Remove the queuing thread and use Lock() and Unlock() instead. - Make it run so well, people wouldn't want to use OSS any more. Both dsound/winealsa: - Allow proper usage of Lock() and Unlock() for sound drivers, it's not used properly or even tested in current dsound code. - Rework some of the dsound code, to allow mixing to be done in winealsa, and fix possible errors that can be caused by it. - Improve the dsound software mixer code to allow mixing and (if possible) be less prone to buffer underruns. The challenge is to get this working right, without too much of an impact hit. I also will have to work around alsa limitations: I cannot make buffers arbitrarily big, while in windows they can be. It seems no 2 programs use dsound in the same way, so I will have to test with various different programs to get everything working. I'll try to get in contact with alsa-devel first, if there is a way to change buffer size to something arbitrary, it is worth it in the long run to use that method. A manual fix seems to be close everything using alsa, then echo 256 /proc/asound/card0/pcm0p/sub0/prealloc, but I am hoping there is an easier way to fix it, in either case I am afraid I will have to put some memory buffer code in winealsa as fallback. If there's still some time left, I'll also try to get some 3d sound code in, using some openal code, the license seems to be lgpl compatible, or I will try to get support for multiple (4, 5.1 ?) speakers working, it depends a little on how fast I can get this to work in a nice shape. Looking for feedback. Cheers, Maarten
Re: const cleanup round 1
after some extra testing I found that it's not that my modification would forbid that, but it would complain about the second parameter not being const(which I thought that the compiler would be fine with auto promoting the WCHAR ** to const WCHAR **). Fair enoug then. Strike those modifications. Should I resubmit without those? or should I put that off until I get a second round ready? On 3/13/07, Eric Pouech [EMAIL PROTECTED] wrote: Mike Schaadt a écrit : string.c: strtolW and strtoulW - constify the endptr value. This is just an output value to indicate where in the array we stoped processing. Change causes this to be the same type as the first value. Reduces number of cast-qual warnings by 6. lnk.c: dump_pidl [line 176] - switched to const. Value is never modified in the function. Removes a cast-qual warning. symbol.c: symbol_clean_string - this function is modifying the string. This should most definitly *not* be a const parameter. It's not even logically const as the the intent of the function is to make the type string Wine-friendly. That requires modifications to that string. diff --git a/include/wine/unicode.h b/include/wine/unicode.h index 83a7d52..4e2caa5 100644 --- a/include/wine/unicode.h +++ b/include/wine/unicode.h @@ -96,8 +96,8 @@ extern int strcmpiW( const WCHAR *str1, extern int strncmpiW( const WCHAR *str1, const WCHAR *str2, int n ); extern int memicmpW( const WCHAR *str1, const WCHAR *str2, int n ); extern WCHAR *strstrW( const WCHAR *str, const WCHAR *sub ); -extern long int strtolW( const WCHAR *nptr, WCHAR **endptr, int base ); -extern unsigned long int strtoulW( const WCHAR *nptr, WCHAR **endptr, int base ); +extern long int strtolW( const WCHAR *nptr, const WCHAR **endptr, int base ); +extern unsigned long int strtoulW( const WCHAR *nptr, const WCHAR **endptr, int base ); this is wrong as you want to be able to write code as: WCHAR* str; WCHAR* p; int val = strtolW(str, p, 10); *p = '\0'; which your modification forbids (ANSI strtol doesn't have the const modifier for endptr) the rest of the patch looks ok -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: Want to be a Wine mentor for Google Summer of Code 2007?
Hey Dan, Say, we (the Wine project) seem to be increasingly leaning on you to run Wine's SoC program. In the early days, we had a committee, and people helping, and stuff. These days, I know that I am guilty of thinking that you're on it, so I can safely ignore it; I fear that a bunch of others of us may be doing the same. Are we letting you down? Do you need help? Cheers, Jeremy
Re: Want to be a Wine mentor for Google Summer of Code 2007?
On Tue, Mar 13, 2007 at 10:23:59AM -0500, Jeremy White wrote: Hey Dan, Say, we (the Wine project) seem to be increasingly leaning on you to run Wine's SoC program. In the early days, we had a committee, and people helping, and stuff. These days, I know that I am guilty of thinking that you're on it, so I can safely ignore it; I fear that a bunch of others of us may be doing the same. Are we letting you down? Do you need help? I have at least asked to be a Mentor again ;) Ciao, Marcus
Re: Add casts to tools/makedep.c
--- Dmitry Timoshkov [EMAIL PROTECTED] wrote: Gerald Pfeifer [EMAIL PROTECTED] wrote: I accidently ended up building Wine using a C++ compiler the other day, and came across the following. -char *p = xmalloc (size); +char *p = (char*) xmalloc (size); That's a problem of C++ not Wine if it can't cope with casting void * to another pointer type. Polluting the whole source with useless casts buys us nothing. That's one of the few incompatibilities between C and C++ actually. C++ doesn't really like void pointers. Regards, Joris 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news
Re: Want to be a Wine mentor for Google Summer of Code 2007?
Marcus Meissner a écrit : On Tue, Mar 13, 2007 at 10:23:59AM -0500, Jeremy White wrote: Hey Dan, Say, we (the Wine project) seem to be increasingly leaning on you to run Wine's SoC program. In the early days, we had a committee, and people helping, and stuff. These days, I know that I am guilty of thinking that you're on it, so I can safely ignore it; I fear that a bunch of others of us may be doing the same. Are we letting you down? Do you need help? I have at least asked to be a Mentor again ;) Ciao, Marcus same here A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: const cleanup round 1
Mike Schaadt a écrit : after some extra testing I found that it's not that my modification would forbid that, but it would complain about the second parameter not being const(which I thought that the compiler would be fine with auto promoting the WCHAR ** to const WCHAR **). Fair enoug then. Strike those modifications. Should I resubmit without those? or should I put that off until I get a second round ready? you'd better remove that part from the part, and resubmit the good part A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: My plans for SOC
Maarten Lankhorst wrote: - Remove the queuing thread and use Lock() and Unlock() instead. There has to be a thread somewhere: for buffers that are DSBPLAY_LOOPING. tom
Re: DirectX 10 start as a SoC project?
Am Dienstag 13 März 2007 03:27 schrieb Kovács András: Seems that there are 3 people interested in that now. I think it should not fail due to the lack of work :-) In case someone has his own idea, feel free to suggest it :-) A few more Direct3D related ideas from me: 1) d3dx9_xy.dll, d3dxof.dll Some helper DLLs. d3dx9 is supposed to be shipped by the game, d3dxof is part of the dx runtime. The problem is that many games do not ship them because windows tends to have them(either shipped, or from another game). The legal situation regarding d3dxof.dll is difficult. They contain various helper functions, from a shader compiler to texture loading. To my knowledge it is no problem to implement a subset for starting, somtthing your favorite game likes, then it can be extended as needed. I think this is interesting for people who like math, and specifically linear algebra. Ivan said he had a look at this DLL, maybe he can comment more on it, and if it is suitable at all. 2) Software Vertex Shaders Not a project for fancy new graphics, but rather to help compatiblity with older cards, for feature completeness and most notably testing. Native DirectX supports Vertex(not pixel) shaders in the CPU, for cards which can't do them, if the application specifically requests this, and for IDirect3DDevice9::ProcessVertices. The use for old cards should be obvious :-) , and ProcessVertices would allow us to test the results of a vertex shader in a more direct way than the visual test does. This will require a lot of x86 assembler work. For performance reasons the d3d asm should be cross-compiled to x86 mmx instructions and then executed directly. The main challenge will be to overcome the architectural differences between a gpu and a normal cpu. Any other ideas? Feel free to suggest :-) Hi, I think, that start working on Dx10 is a great opportunity to learn about wined3d, and Microsoft's new platform. I would like to apply, because i want to contribute to open source projects, and i'm really interested in wine, especially in wined3d. I have some patches in the tree, and I really would like to work on together. Best Regards, Andras kovacs
Re: wordpad: update Polish translation
Hi Mikołaj, Mikołaj Zalewski wrote: + +STRINGTABLE DISCARDABLE +BEGIN +STRING_RICHTEXT_FILES_RTF, Tekst sformatowany - RTF (*.rtf) +STRING_TEXT_FILES_TXT, Document tekstowy (*.txt) This is a typo, it should be Dokument. Jacek
Re: shell32: update Polish translation
Hi Mikołaj, Mikołaj Zalewski wrote: - IDS_OVERWRITEFOLDER_TEXT This folder already contains a folder named '%1'.\n\n\ - If the files in the destination folder have the same names as files in the\n\ - selected folder they will be replaced. Do you still want to move or copy\n\ - the folder? + IDS_OVERWRITEFOLDER_TEXT Ten folder ju� zawiera folder o nazwie '%1'.\n\n\ + Je�eli w docelowym folderze wyst�pi� pliki o takich zamych nazwach jak\n\ This is a typo, it should be samych nazwach. Jacek
Re: DirectX 10 start as a SoC project?
Read the other thread for way more information. You would do best to follow that model instead of thinking large scale lump all that you can of 10 in, they're thinking more framework. On 3/12/07, Kovács András [EMAIL PROTECTED] wrote: Hi, I think, that start working on Dx10 is a great opportunity to learn about wined3d, and Microsoft's new platform. I would like to apply, because i want to contribute to open source projects, and i'm really interested in wine, especially in wined3d. I have some patches in the tree, and I really would like to work on together. Best Regards, Andras kovacs -- -- andras NetClub Lamarr csevego.net [EMAIL PROTECTED] -- -- Cheers, Bryan
Re: My plans for SOC
Frankly if you could get ALSA working perfectly, and DSOUND to do what it's supposed to without underruns (As in WoW, with default settings) You would make my life a lot easier. I answer so many questions about sound it's not even funny. Out of the box Just working sound would be pretty great. OSS is *alright* and all but it doesn't work so well with software mixing, ALSA however is easy to set up. On 3/13/07, Maarten Lankhorst [EMAIL PROTECTED] wrote: For the summer of code I'm planning to improve the dsound code and alsa code, to make alsa finally better then OSS, in a way that has a will get accepted into the wine tree, for that I'm thinking of improving on the following fronts: Winealsa: - Add mixer device and aux controls - Implement dsound capture - Seperate the initialisation of the directsound code from the waveout code, to allow creation of multiple dmix devices. - Try to configure alsa to allow arbitrarily big buffers, working around the alsa problem that only up to a certain amount can be allocated for buffers, certain programs (for example winamp) may require more. - Remove the queuing thread and use Lock() and Unlock() instead. - Make it run so well, people wouldn't want to use OSS any more. Both dsound/winealsa: - Allow proper usage of Lock() and Unlock() for sound drivers, it's not used properly or even tested in current dsound code. - Rework some of the dsound code, to allow mixing to be done in winealsa, and fix possible errors that can be caused by it. - Improve the dsound software mixer code to allow mixing and (if possible) be less prone to buffer underruns. The challenge is to get this working right, without too much of an impact hit. I also will have to work around alsa limitations: I cannot make buffers arbitrarily big, while in windows they can be. It seems no 2 programs use dsound in the same way, so I will have to test with various different programs to get everything working. I'll try to get in contact with alsa-devel first, if there is a way to change buffer size to something arbitrary, it is worth it in the long run to use that method. A manual fix seems to be close everything using alsa, then echo 256 /proc/asound/card0/pcm0p/sub0/prealloc, but I am hoping there is an easier way to fix it, in either case I am afraid I will have to put some memory buffer code in winealsa as fallback. If there's still some time left, I'll also try to get some 3d sound code in, using some openal code, the license seems to be lgpl compatible, or I will try to get support for multiple (4, 5.1 ?) speakers working, it depends a little on how fast I can get this to work in a nice shape. Looking for feedback. Cheers, Maarten -- Cheers, Bryan
Re: HtmlHelp status, winecfg and SoC proposal
Hi Paul, Paul Wise wrote: Paul seems to be excited about Wine, so hhm relicensing should sound OK for him, IMHO. I've previously offered to relicence the hhm code for inclusion in both chmlib and libmspack, but it seems neither project took up this offer. I don't think the hhm code belongs anywhere other than in one of them. The current version was more of a proof-of-concept, I wanted to push the code into a chm reading/writing library. IIRC, wine's itss.dll uses libmspack, so perhaps it should go there? Yes, it should go to itss.dll to support writing mode in storages. But we can't use itss in hhc replacement as it has to be useful for Wine compilation. It means that we need plain UNIX app. That's the code duplication I wrote about. Also, if it does get included, I'd *STRONGLY* request/suggest that the code be modified to also include a README.hhm.txt (or similar) file saying something like This file was not produced by Microsoft's HtmlHelp compiler, it may have incompatibilities preventing it from being used on Windows. I think this is an important inclusion in any non-MS compiler, one which I haven't got around to adding to hhm yet. Then we could add such README about whole Wine :-) Our aim is to improve things to be useful, not to write something and tell users to not use it because it sucks... I've also previously (2003) pointed wine-devel at chmspec and offered to relicence chmdeco code for use in a wine version of hh.exe. No-one was interested though, saying that a CHM viewer was already implemented and then deteriorating into a thread about which browser to embed and forking KHTML and Mozilla and so on. Things have changed. Now Wine has MSHTM/WebBrowser implementation that make it possible to support HtmlHelp. But only if proved it isn't breaking M$ licences [2], right? The licence says this: * Limitations on Reverse-Engineering, Decompilation, and Disassembly. You may not reverse- engineer, decompile, or disassemble the SOFTWARE PRODUCT, except and only to the extent that such activity is expressly permitted by applicable law notwithstanding this limitation. As written in the chmspec colophon, I didn't do any disassembly of Microsoft stuff, only black-box format discovery. Mainly this was by sending different inputs to Microsoft's hhc and observing the output, as well as looking at existing samples of CHM files. I imagine that is probably reverse-engineering according to Microsoft (although they haven't contacted me at all, so maybe not). http://chmspec.nongnu.org/latest/Colophon.html That's fine for sure. Thanks for your work, it was very helpful to me! Frankly I haven't done anywhere near enough reverse engineering of the internal CHM formats to even be close to thinking about implementing a full-blown CHM compiler that would create correct CHMs. There is enough info for CHM readers like chmdeco, xCHM and so on to be written, but not for compilers. Patches to chmspec are welcome though :) I have to disagree. Surely it's enough to implement a compiler that will work with Wine's HtmlHelp. Also it should be possible to implement a compiler that will work with native hhctrl.ocx. Even if not everything is documented, dummy values should be good enough for most uncovered things. Also more things that will be needed may be discovered during SoC. Why does wine want a CHM compiler anyway? Can't Microsoft's one be used? Microsoft's one isn't distributed with the OS anyway. If we want to include chm files to Wine (like help for winecfg) we have to be able to compile them. Perhaps some apps ported with winelib would benefit from chm compiler. Thanks, Jacek
Re: localspl: add Polish translation
Hi Mikołaj, Mikołaj Zalewski wrote: +IDS_NOTHINGTOCONFIG Ten port nie ma opcji, kt�re mo�na by skonfigurowa� +} It doesn't sound good to me. How about Ten port nie ma opcji do skonfigurowania or just remove by from your version? Jacek
Re: Makefiles: Be less verbose when performing make rules by only printing the command being executed and the source and/or target file.
Robert Shearman a écrit : The old behaviour can be turned back on by setting the VERBOSE environment variable to yes. .s.o: $(AS) -o $@ $ $(MODULE): $(OBJS) Makefile.in - $(RM) $@ - $(AR) $@ $(OBJS) - $(RANLIB) $@ + @$(RM) $@ + @$(MAKERULE) '[AR] $@' $(AR) $@ $(OBJS) + @$(MAKERULE) '[RANLIB] $@' $(RANLIB) $@ we'll miss the echo for the $(RM) command in verbose mode IMO, we should use here something like @$(MAKERULE) '' $(RM)... and handle the empty $1 in makerule A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Issue with GetTokenInformation?
Hi, As I'm still trying to get Process Explorer running perfectly, I've noticed that the usernames for the processes are not correct. The attached patch shows the issue. I'm not sure if this test-patch should go to wine-patches as I'm not sure my test is correct (or in the correct place). It succeeds on W2K3. Maybe someone more knowledgeable about the Token stuff could have a look? Cheers, Paul diff --git a/dlls/advapi32/tests/security.c b/dlls/advapi32/tests/security.c index 3e8459e..616afa8 100644 --- a/dlls/advapi32/tests/security.c +++ b/dlls/advapi32/tests/security.c @@ -849,6 +849,11 @@ static void test_token_attr(void) DWORD i, GLE; LPSTR SidString; SECURITY_IMPERSONATION_LEVEL ImpersonationLevel; +CHAR accountA[MAX_PATH], domainA[MAX_PATH]; +DWORD real_acc_sizeA, real_dom_sizeA; +SID_NAME_USE use; +CHAR user_name[UNLEN + 1]; +DWORD user_size; /* cygwin-like use case */ ret = OpenProcessToken(GetCurrentProcess(), MAXIMUM_ALLOWED, Token); @@ -913,6 +918,21 @@ static void test_token_attr(void) pConvertSidToStringSidA(User-User.Sid, SidString); trace(TokenUser: %s attr: 0x%08x\n, SidString, User-User.Attributes); + +/* Retrieve the named user for this SID and compare it to the username, + * they should match + */ +real_acc_sizeA = MAX_PATH; +real_dom_sizeA = MAX_PATH; +ret = LookupAccountSidA(NULL, User-User.Sid, accountA, real_acc_sizeA, domainA, real_dom_sizeA, use); + +user_size = UNLEN + 1; +ret = GetUserNameA(user_name, user_size); + +/* todo_wine */ +ok(!lstrcmp(accountA, user_name), Expected %s, got %s\n, user_name, accountA); +/* */ + LocalFree(SidString); HeapFree(GetProcessHeap(), 0, User);
Re: [0/9] CMD.EXE resubmits
Tirsdag 13 mars 2007 22:03, skrev Ann Jason Edmeades: Resubmitting the patchset from yesterday having fixed up the mallocs/reallocs/frees to HeapAllocs/HeapReAllocs/HeapFrees, and resolved conflicts with those already committed. Note: I have been experimenting from sending the emails directly from git send-email, and this will be the first ones sent that way, so if there are any problems please let me know Jason There does not seem to be a patch attached. Alexander N. Sørnes
Re: kernel32: MultiByteToWideChar: MB_USEGLYPHCHARS fix
Andrew O. Shadoura [EMAIL PROTECTED] writes: 2. MB_USEGLYPHCHARS Use glyph characters instead of control characters. 'control characters' in this context are _Unicode_ characters below U+0020. dst is a pointer to WCHAR string - this means it is Unicode string. So, we don't need to take into account any codepages, because codepage of dst is Unicode Yes, but apparently this is only supposed to do something for OEM codepages, so you'd still have to take that into account. Writing some test cases is probably a good idea. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [0/9] CMD.EXE resubmits
Tirsdag 13 mars 2007 22:10, skrev Alexander Nicolaysen Sørnes: Tirsdag 13 mars 2007 22:03, skrev Ann Jason Edmeades: Resubmitting the patchset from yesterday having fixed up the mallocs/reallocs/frees to HeapAllocs/HeapReAllocs/HeapFrees, and resolved conflicts with those already committed. Note: I have been experimenting from sending the emails directly from git send-email, and this will be the first ones sent that way, so if there are any problems please let me know Jason There does not seem to be a patch attached. Sorry, my bad. Alexander N. Sørnes
some emails not arriving to wine-patches (was CMD.EXE resubmits)
There does not seem to be a patch attached. They followed However - I sent all 9, and got immediate cc: copies returned to me for all 9. Browsing the patches through either gmame or wine-patches archives, only shows 1,2,5 and 7 got through. This is the same as yesterday when a number of the 19 I sent failed to get through and vanished (no rejection emails or anything).. - Can anyone who subscribes to wine-patches tell me if they received any more than 1,2,5 and 7? - Anyone got any ideas as to what might be going on, or how to persue it... I'd blame the ISP but I've never (knowingly) lost emails before, only when sent to wine-patches! I did contact the ISP help desk and they said its probably a problem with the receiving mail server (surprise, surprise) Jason
re: Want to be a Wine mentor for Google Summer of Code 2007?
Jeremy wrote: Say, we (the Wine project) seem to be increasingly leaning on you to run Wine's SoC program. In the early days, we had a committee, and people helping, and stuff. These days, I know that I am guilty of thinking that you're on it, so I can safely ignore it; I fear that a bunch of others of us may be doing the same. Are we letting you down? Do you need help? I'm fine this year, but considering how I missed the deadline (we were saved by LH's kindness), it would probably be a good idea to pick somebody else to be admin next year. The committee should probably just be the mentors plus you and Alexandre (if you/he are interested). - Dan
Re: some emails not arriving to wine-patches (was CMD.EXE resubmits)
Ann Jason Edmeades wrote: As an FYI I sent the same patchset to another email account (not on my ISP, just one of the free ones) and they all got through 4 times. It would start to point to the wine-patches side of things, but I have never seen anyone else have problems Note I am not seeing any rejection emails either You won't get rejection emails. The patches are not showing up in the moderation queue, and you only get rejections if they show up there. Though I don't know where they are going. I think a month or two ago Jeremy mentioned making some changes to limit the number of simultaneous email connections... or something like that. I really didn't understand it, so I didn't pay close attention.
Re: some emails not arriving to wine-patches (was CMD.EXE resubmits)
I've asked Jeremy to take a look and see if anything obvious is going on. Cheers, Jeremy Ann Jason Edmeades wrote: As an FYI I sent the same patchset to another email account (not on my ISP, just one of the free ones) and they all got through 4 times. It would start to point to the wine-patches side of things, but I have never seen anyone else have problems Note I am not seeing any rejection emails either Jason
Re: Want to be a Wine mentor for Google Summer of Code 2007?
On Tuesday 13 March 2007 23:06, Dan Kegel wrote: Are we letting you down? Do you need help? I'm fine this year, but considering how I missed the deadline (we were saved by LH's kindness), it would probably be a good idea to pick somebody else to be admin next year. I'll try to get in as a student again this year, but that's about it for my wall space for certificates, and I'll probably be out of university for the next SoC, or at least in the final stages of writing my thesis. Still, as I know SoC pretty well from the student perspective, I'd be happy to do this next year. Cheers, Kai -- Kai Blin, kai Dot blin At gmail Dot com WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpXDO4EoNs8r.pgp Description: PGP signature
Re: My plans for SOC
Am Dienstag 13 März 2007 15:32 schrieb Maarten Lankhorst: For the summer of code I'm planning to improve the dsound code and alsa code, to make alsa finally better then OSS, in a way that has a will get accepted into the wine tree, for that I'm thinking of improving on the following fronts: ... Sounds like a lot of coding for you this summer :-) pgphj503Ck2UK.pgp Description: PGP signature
Re: wined3d: Allow SetCursorProperties on existing cursor
Am Dienstag 13 März 2007 03:44 schrieb Erich Hoover:
Real Name:
Erich Hoover
Changelog:
wined3d: Allow SetCursorProperties on existing cursor
Looks good to me, except one cosmetic issue:
if(pCursorBitmap) {
+WINED3DLOCKED_RECT rect;
+.
/* MSDN: Cursor must be A8R8G8B8 */
You are adding trailing whitespaces here. I think git or AJs filters filter
them out, but they tend causing merging problems for me if my patches contain
some of them.
pgp2OB4CuuR2P.pgp
Description: PGP signature
Re: HtmlHelp status, winecfg and SoC proposal
On Tue, 2007-03-13 at 20:13 +0100, Jacek Caban wrote: Yes, it should go to itss.dll to support writing mode in storages. But we can't use itss in hhc replacement as it has to be useful for Wine compilation. It means that we need plain UNIX app. That's the code duplication I wrote about. AFAIK, itss.dll doesn't know anything about internal CHM formats, it just deals with the InfoTech Storage format (container format for CHMs), so no need for code duplication at all. For a wine version of hha.dll/hhctrl.ocx and so on, there is always the possibility of creating a libhtmlhelp or something like that that can read and write the internal CHM formats, that uses a write-enabled libmspack or chmlib. Then use that library in wine's version of hha.dll/hhctrl.ocx/etc as well as the compiler, no need for code duplication at all. The current chmdeco code could form the initial decoding part of that library and write support could form around that. Also, if it does get included, I'd *STRONGLY* request/suggest that the code be modified to also include a README.hhm.txt (or similar) file saying something like This file was not produced by Microsoft's HtmlHelp compiler, it may have incompatibilities preventing it from being used on Windows. I think this is an important inclusion in any non-MS compiler, one which I haven't got around to adding to hhm yet. Then we could add such README about whole Wine :-) Our aim is to improve things to be useful, not to write something and tell users to not use it because it sucks... To be clear, this file would not be visible to users unless they unpack the files with extract_chmLib or istorage.exe or something. The idea was to document the fact that those files are non-Microsoft, so if there are issues with those files later, the person investigating those issues will immediately know that the file is non-Microsoft and then be able to direct any bug reports to the appropriate place. So it wouldn't be telling users not to use it, it would be telling recipients of hhm-created files where to go in case of problems. Things have changed. Now Wine has MSHTM/WebBrowser implementation that make it possible to support HtmlHelp. That is good to hear. I have to disagree. Surely it's enough to implement a compiler that will work with Wine's HtmlHelp. Also it should be possible to implement a compiler that will work with native hhctrl.ocx. Even if not everything is documented, dummy values should be good enough for most uncovered things. Also more things that will be needed may be discovered during SoC. I suppose it may be possible, I'd still suggest adding a README.hhm.txt to CHM files produced by hhm to warn that it may still be using dummy values. If you want to implement that I'm happy to provide explanations of any unclear bits in chmspec and accept chmspec bugs or provide other help on the project. If we want to include chm files to Wine (like help for winecfg) we have to be able to compile them. Perhaps some apps ported with winelib would benefit from chm compiler. Ok, that makes sense. I don't really understand the desire to use CHM files in Wine, that isn't relevant to this conversation though. -- bye, pabs http://pabs.zip.to signature.asc Description: This is a digitally signed message part
Re: DirectX 10 start as a SoC project?
On Tue, Mar 13, 2007 at 07:05:56PM +0100, Stefan Dösinger wrote: 2) Software Vertex Shaders Not a project for fancy new graphics, but rather to help compatiblity with older cards, for feature completeness and most notably testing. Native DirectX supports Vertex(not pixel) shaders in the CPU, for cards which can't do them, if the application specifically requests this, and for IDirect3DDevice9::ProcessVertices. The use for old cards should be obvious :-) , and ProcessVertices would allow us to test the results of a vertex shader in a more direct way than the visual test does. This will require a lot of x86 assembler work. For performance reasons the d3d asm should be cross-compiled to x86 mmx instructions and then executed directly. The main challenge will be to overcome the architectural differences between a gpu and a normal cpu. Why duplicate this? We should be able to use the GLSL or ARB shader software emulation the/a opengl lib might provide. I guess dri+mesa does provide this for cards that don't support shading, but at least the stand alone (non-dri) mesa supports shading. Jan
