Re: Compiling dbghelp with MinGW
On Sat, 13 Dec 2008, Eric Pouech wrote: [...] 1) #ifdef-out regexp support if regex.h is missing? Maybe with an autoconf check for regcomp()? 2) Add some reg*() stubs that do nothing if regex.h co are missing? [...] 1,2) most of the dbghelp code will be of no use if no regex support is present It still feels wrong for Wine to fail compiling just because a regular expression library is missing. If we can compile Wine without X we should be able to compile it without a regular expression library. [...] *** new option *** 5) use a regex lib for mingw... that work(ed) just fine http://sourceforge.net/project/showfiles.php?group_id=2435package_id=73286release_id=140957 I will install it. It would be nice if they had a Debian package for it. -- Francois Gouget fgou...@free.fr http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.
Re: mshtml: Add some interfaces in mshtml.idl (try 3) (resend)
Hi Konstantin, Konstantin Kondratyuk kondrat...@etersoft.ru wrote in message news:200812181251.50439.kondrat...@etersoft.ru... Add: ILineInfo IDisplayPointer IDisplayPointer IHTMLComputedStyle IDisplayServices IMarkupServices -- You have converted some OLECHAR* to unsigned short* in functions InsertText, CreateElement to name a few. Best Regards Alistair Leslie-Hughes
Re: [1/2] imm32: Fix the ImmIsUIMessageA/W.
Aric Stewart a...@codeweavers.com writes: Since I value your input in imm32 and i do a lot of work there. If you would like to send me that high level overview then I can see if it works into wine. That way you can continue to contribute and we do not compromise the source code. No, please don't do that. We don't want to have people disassemble Windows code at all, even to write high level descriptions. There's simply no need for it, just write test cases. -- Alexandre Julliard julli...@winehq.org
re: winewtsn: add a new program that shows a dialog to inform about a crash
Alexandre wrote: I'd suggest to do that in winedbg, there's no need to add another Wine-specific program for that. Windows uses three different automatically started debuggers: the visual C++ debugger for average programmers, windbg for superprogrammers, and Dr. Watson for users who just need a user-friendly crash handler. I think Mikolaj was simply trying to provide an implementation of the latter. Does it really make sense to make one program serve both roles, given that Microsoft doesn't do it that way? - Dan
Re: [1/2] imm32: Fix the ImmIsUIMessageA/W.
Ahh ok, thanks. Will do. -aric Alexandre Julliard wrote: Aric Stewart a...@codeweavers.com writes: Since I value your input in imm32 and i do a lot of work there. If you would like to send me that high level overview then I can see if it works into wine. That way you can continue to contribute and we do not compromise the source code. No, please don't do that. We don't want to have people disassemble Windows code at all, even to write high level descriptions. There's simply no need for it, just write test cases.
Re: Better user feedback and better user experience (idea)
On Wed, 17 Dec 2008, Austin English wrote: In a few years when Wine is more developed and has most the API implemented, this may be useful, but there's still a lot to do, and we don't need more reports to tell us this. Keep in mind that the Windows API is a moving target. In a few years, the API will be no more completely implemented than it is today -- it will just be a different set of calls that aren't done than it is today. Steve Brown sbro...@umbc.edu
Re: Better user feedback and better user experience (idea)
On Thu, Dec 18, 2008 at 8:07 AM, Steve Brown sbro...@umbc.edu wrote: On Wed, 17 Dec 2008, Austin English wrote: In a few years when Wine is more developed and has most the API implemented, this may be useful, but there's still a lot to do, and we don't need more reports to tell us this. Keep in mind that the Windows API is a moving target. In a few years, the API will be no more completely implemented than it is today -- it will just be a different set of calls that aren't done than it is today. Steve Brown sbro...@umbc.edu Of course, didn't meant to imply that it will be complete at that time, but will be moreso than it is now, especially in regards to older API functions. -- -Austin
Re: wininet: Relax a notification test.
Hans Leidekker wrote: diff --git a/dlls/wininet/tests/http.c b/dlls/wininet/tests/http.c index 6554680..8b3a8f8 100644 --- a/dlls/wininet/tests/http.c +++ b/dlls/wininet/tests/http.c @@ -325,8 +325,8 @@ static void InternetReadFile_test(int flags) SET_EXPECT2(INTERNET_STATUS_REQUEST_SENT, 2); SET_EXPECT2(INTERNET_STATUS_RECEIVING_RESPONSE, 2); SET_EXPECT2(INTERNET_STATUS_RESPONSE_RECEIVED, 2); -SET_EXPECT2(INTERNET_STATUS_CLOSING_CONNECTION, 2); -SET_EXPECT2(INTERNET_STATUS_CONNECTION_CLOSED, 2); +SET_OPTIONAL2(INTERNET_STATUS_CLOSING_CONNECTION, 2); +SET_OPTIONAL2(INTERNET_STATUS_CONNECTION_CLOSED, 2); SET_EXPECT(INTERNET_STATUS_REDIRECT); SET_OPTIONAL(INTERNET_STATUS_CONNECTING_TO_SERVER); SET_OPTIONAL(INTERNET_STATUS_CONNECTED_TO_SERVER); Hi Hans, Apparently that's not enough to fix the tests. Although it's set to be optional we are still using CHECK_NOTIFIED2 that doesn't make use of the optional parameter. -- Cheers, Paul.
RE: WineD3D: add some new GL extensions
Did you send it to wine-devel intentionally? IMHO there's not much use for adding the extensions to the extension list without making use of them. I think this should be done in one patch. -Original Message- From: wine-devel-boun...@winehq.org [mailto:wine-devel- boun...@winehq.org] On Behalf Of Roderick Colenbrander Sent: Wednesday, December 17, 2008 11:22 PM To: wine-devel@winehq.org Subject: WineD3D: add some new GL extensions Hi, Add some new GL extensions which are needed for better d3d9 floating point support for R32F/RG32F and friends. Roderick -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a
Re: Better user feedback and better user experience (idea)
2008/12/18 Ben Klein shackl...@gmail.com: 2008/12/18 Sander Devrieze s.devri...@linux.be: 2008/12/17 Scott Ritchie sc...@open-vote.org: snip If it's that users blame the distro when it's a Wine problem, then we can present them with some sort of information before installing (or perhaps running) Wine. After that we should get out of the way and let them use Wine as normal. Is it a goal for Wine to be included as standard in distros? I'd say not. The correct solution is *nix-native applications. E.g., how many people use utorrent in Wine when they could use Deluge or Transmission? Sure, Wine's goal should include support for apps like utorrent (in that Wine's goal is to run as many Windows apps as possible), but they shouldn't be prefered over *nix-native apps. Wine should go out of way when the Windows application is known to run very well under Wine or when the user submitted feedback for this application in the past. Also, the user easily can skip the dialog. Known by whom? Are you suggesting appdb scraping? No, I was thinking about including a list of hashes for the applications that are officially supported in the Wine distribution. If the problem is that we're not getting enough feedback, then a default feedback nag might not be the best answer either. Writing an elaborate system to tell us about known problems isn't particularly helpful; It shouldn't be an elaborate system: it can be as easy as asking the user to click on a button to send a list of API calls, used DLLs, a hash of the .exe binary, some critical information of his system, amongst others to the Wine project. User based input in the feedback form may or may not be a good thing; I just gave this as an example; it is no necessary element in what I am proposing. Sounds elaborate to me :) Though the winewatson sounds like it could handle this sort of thing. I guess this kind of feedback can be very powerful to Wine coders to create statistics like these: * Most popular API calls * Least popular API calls * Most common API calls that make applications fail * Unimplemented features used by very uncommon software (e.g. custom-built applications within companies) * Predicting the likelihood that a specific API call will be used when another API call is used in an application Maybe this information can be useful to detect which applications are affected by a bug in Wine. When this is known, testers can verify in multiple applications if the bug really is fixed in all applications. From what I've seen, most bugs in Wine aren't detectable by software - it THINKS it's working fine, but the user can tell it's not :) In any case, this would require a potentially large database of known bugs and their symptoms ... I meant that this database can be used to see if a *manually* reported bug may also affect other applications. So, developers and testers can get a list of software that can be used to see if the bug is fixed. reports from stable or nonlatest versions would be largely ignored, and users of the latest beta can be asked to contribute in other ways, such as on the download page itself. Remember, it doesn't take much work for us to know that an application doesn't work - a single bug report can do that. Once we have that, we don't need to ask a million other users (literally) for confirmation. Only geeks file good bug reports. Normal people don't care and will not spend energy on this. There's been a lot of talk recently about targeting Wine towards end-users, e.g. the redesign of the website. It sounds like a great idea, but Wine is still very much a developer's tool. It's not user-friendly, and it won't be for a very long time, if ever. Most end-users primarily don't report bugs because they don't want to spend time on this. winewatson sounds like a developer's debugging tool, but it could prove useful for improving bad bug reports. Note that Microsoft has a system where any old application crash can send a bug report to Microsoft. It's basically spamming yourself :) -- Mvg, Sander Devrieze.
Re: RE: WineD3D: add some new GL extensions
Argh .. I already wondered why it wasn't added. Guess I wasn't very awake .. I'll resubmit it later today when I also do something useful with it. Thanks, Roderick Did you send it to wine-devel intentionally? IMHO there's not much use for adding the extensions to the extension list without making use of them. I think this should be done in one patch. -Original Message- From: wine-devel-boun...@winehq.org [mailto:wine-devel- boun...@winehq.org] On Behalf Of Roderick Colenbrander Sent: Wednesday, December 17, 2008 11:22 PM To: wine-devel@winehq.org Subject: WineD3D: add some new GL extensions Hi, Add some new GL extensions which are needed for better d3d9 floating point support for R32F/RG32F and friends. Roderick -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
implicit declaration of function '_mkdir'
I am mostly offline (2s ping times) for another two weeks, but noticed the following starting a couple of days ago on my nightly FreeBSD 6.4 tester: server.c:755: warning: implicit declaration of function '_mkdir' shellpath.c:2163: warning: implicit declaration of function '_mkdir' shfldr_unixfs.c:1745: warning: implicit declaration of function '_mkdir' xdg.c:253: warning: implicit declaration of function '_mkdir' theme.c:966: warning: implicit declaration of function '_mkdir' winemenubuilder.c:707: warning: implicit declaration of function '_mkdir' fd.c:1562: warning: implicit declaration of function '_mkdir' request.c:530: warning: implicit declaration of function '_mkdir' Perhaps one of you has an idea where this might come from and how to avoid it? Gerald
winecfg volume serial number
Hi, I just sent a bug-fix to wine-patches to prevent a crash in winecfg when editing the volume serial number input field, together with some unrelated thoughts about winecfg and the device/volume serial number handling. Then I realized that wine-patches is not a good place for discussion. So here are the ideas about winecfg's GUI: - Maybe the serial input field should be initialized with %08X instead of %X to hint at the format? E.g. input of serial numbers like 1122-dacf as printed by DIR produce 1122 in winecfg, due to strtoul(). - Possibly the input size should be restricted to 8 characters in the GUI? - Maybe winecfg should echo the hex number it read into the input field, no later than apply time? Currently one needs to select another drive, then come back to see what it got. Note that winecmd's DIR prints the number in lower case, while MS-w2k DOS window's DIR prints upper case. BTW, winecfg does not seem to be able to set .windows-label anymore: trace:winecfg:apply_drive_changes warn:winecfg:set_drive_label unable to set volume label for devicename of LE:\\, label of Lxyz trace:winecfg:PRINTERROR error: 'Access denied' Looks like http://bugs.winehq.org/show_bug.cgi?id=13273 Regards, Jörg Höhle
Re: server: implement move/rename change notifications and support for multiple change notification in one reply
Dan Kegel wrote: On Tue, Dec 16, 2008 at 5:21 PM, Michael Pujos pujos.mich...@laposte.net wrote: I don't see an attachment to http://www.winehq.org/pipermail/wine-patches/2008-December/066224.html or rather, there's only a zero-length one. I just attached (In thunderbird) the file outputted by git format-patch --keep-subject origin Curiously the link above point to a zero length file but I received it correctly in my e-mail client from the mailing-list... That archive is a bit finicky. I see the attachment in another archive: http://marc.info/?l=wine-patchesm=122947592925831w=2 Suggestion: next time use a shorter filename, maybe that's what screwed up the archive. Ah ok, I've noticed it also happens with other patches posted It looks like you're changing the protocol. Will old clients be able to connect successfully? It looks like they won't. you need to support old clients. We're not allowed to break compatibility now that we've released wine-1.0. - Dan The protocol is slightly changed between read_changes_apc() in ntdll and the server to support return of multiple FILE_NOTIFY_INFORMATION structs at a time. This is transparent to win32 programs (is that what you are calling client ? 'm still a bit new to wine terminology :). using this API (ReadDirectoryChangeW) and I took great care to have all the tests pass.
Re: implicit declaration of function '_mkdir'
On Sun, Dec 14, 2008 at 2:29 AM, Gerald Pfeifer ger...@pfeifer.com wrote: I am mostly offline (2s ping times) for another two weeks, but noticed the following starting a couple of days ago on my nightly FreeBSD 6.4 tester: server.c:755: warning: implicit declaration of function '_mkdir' shellpath.c:2163: warning: implicit declaration of function '_mkdir' shfldr_unixfs.c:1745: warning: implicit declaration of function '_mkdir' xdg.c:253: warning: implicit declaration of function '_mkdir' theme.c:966: warning: implicit declaration of function '_mkdir' winemenubuilder.c:707: warning: implicit declaration of function '_mkdir' fd.c:1562: warning: implicit declaration of function '_mkdir' request.c:530: warning: implicit declaration of function '_mkdir' Perhaps one of you has an idea where this might come from and how to avoid it? You can use git offline to do a regression test. Might give you some better clues. -- James Hawkins
Re: wine-1.2 release criteria?
On Mon, Dec 15, 2008 at 9:24 AM, Paul Vriens paul.vriens.w...@gmail.com wrote: Dan Kegel wrote: - Tests that pass We're making progress here, but it's hard to quantify. http://test.winehq.org shows some runs still failing 20% of the tests, and others failing 0.3%, because we don't have a consistent set of machines running the tests. I would love to see that site add a feature showing the failure history for particular machines. I am doing this locally with my (6) testboxes. This way it's very easy to spot differences or even flaky and inconsitent test results (see attached screenshot). This is nice for me as I only have 1 box per OS. Not sure how this will work out on test.winehq.org. And I'm not even talking about the extra amount of diskspace we need for this. Perhaps limit it to developers, or require a registration? -- -Austin
Re: winecfg volume serial number
wine-devel-requ...@winehq.org wrote: Date: Tue, 16 Dec 2008 13:52:00 +0100 From: Hoehle, Joerg-Cyril joerg-cyril.hoe...@t-systems.com Subject: winecfg volume serial number To: wine-devel@winehq.org Message-ID: 47cc5abb01651443a88db8ec5b4d657b01c8f...@s4de8psaank.mitte.t-com.de Content-Type: text/plain;charset=iso-8859-1 Hi, I just sent a bug-fix to wine-patches to prevent a crash in winecfg when editing the volume serial number input field, together with some unrelated thoughts about winecfg and the device/volume serial number handling. Then I realized that wine-patches is not a good place for discussion. So here are the ideas about winecfg's GUI: It doesn't make sense to me to rely on writing to a file to set the windows serial number or label. What about readonly disks? I think those values should be in the registry. Or at least check the registry should be a fallback if .windows-serial or .windows-label does not exist. I am stuck now because an installer program is looking for a CD of a certain label. I can't fudge in the label because it's a CD that I can't write to. Is anyone working on this issue, or agree/disagree? ... mo
Re: Unused vtables and debug channels
Andrew Talbot a écrit : Christian Costa wrote: Hi Andrew, BTW, if the vtable are removed, there may be some unused functions. Will they be removed as well ? Bye, Christian Hi Christian, Because I was mindful not to remove such things lightly, that is why I sought feedback from the community, and I shall respect the views expressed by some, therefore, to leave the vtables alone. However, I do agree with Henri's view that it is the keeping of pieces of code needs to be justified, and so am inclined to remove any genuinely unused Wine debug channels, since they are comparatively simple items and very easy to resurrect if eventually required. Thanks to everyone, Hi Andrew, Cleaning the code is a good thing. If we take the time to do it the right way, that's fine. Christian
Re: winecfg volume serial number
On Thu, Dec 18, 2008 at 12:31 PM, Michael Ost m...@museresearch.com wrote: wine-devel-requ...@winehq.org wrote: Date: Tue, 16 Dec 2008 13:52:00 +0100 From: Hoehle, Joerg-Cyril joerg-cyril.hoe...@t-systems.com Subject: winecfg volume serial number To: wine-devel@winehq.org Message-ID: 47cc5abb01651443a88db8ec5b4d657b01c8f...@s4de8psaank.mitte.t-com.de Content-Type: text/plain;charset=iso-8859-1 Hi, I just sent a bug-fix to wine-patches to prevent a crash in winecfg when editing the volume serial number input field, together with some unrelated thoughts about winecfg and the device/volume serial number handling. Then I realized that wine-patches is not a good place for discussion. So here are the ideas about winecfg's GUI: It doesn't make sense to me to rely on writing to a file to set the windows serial number or label. What about readonly disks? I think those values should be in the registry. Or at least check the registry should be a fallback if .windows-serial or .windows-label does not exist. I am stuck now because an installer program is looking for a CD of a certain label. I can't fudge in the label because it's a CD that I can't write to. Is anyone working on this issue, or agree/disagree? ... mo The label of the CD is read from the disk. If you're using a mounted ISO, you have to fix the access rights of the loopback file representing the ISO file. -- James Hawkins
Re: Unused vtables and debug channels
Hi, I would suggest to keep the ones in pin.c. The file pin.c is a kind of template collection. Christian Maarten Lankhorst a écrit : Hi Andrew, Andrew Talbot schreef: It appears that the following vtables and Wine debug channels are not being used, so I am considering removing them. Please let me know, therefore, if you have plans for any of them and want them kept. Vtables: MemInputPin_Vtblquartz/nullrenderer.c OutputPin_Vtbl* quartz/pin.c InputPin_Vtbl* quartz/pin.c PullPin_Vtbl* quartz/pin.c MemInputPin_Vtblquartz/transform.c MemInputPin_Vtblquartz/videorenderer.c Feel free to remove the quartz ones, it should be harmless. Cheers, Maarten.
Re: Functions that should be static
Hi Francois, For 1) Why not adding a keyword to mark these functions. Something like WINAPI which resolve to nothing but that can be tracked by your script. I would add another item for more object oriented stuff. Some default implentations can be written but not always used. This is sort of templates. This is used in quartz for example. Christian Francois Gouget a écrit : I have attached a script that identifies functions that should be made static (among other things). There are approximately 450 of them, there should be pretty efw false positives, and I will look into them eventually. But if someone beats me to it I sure won't complain g. So if you do try to tackle them you are likely to find that they fall into one of the following categories: 1) Unused debug functions. For instance for dumping the contents of a structure to stderr. Although these are unused we probably want to keep them. Let me know about these and I will put them in an exception list. 2) Functions that should be exported by a spec file It happens. Sometimes the developer implementing a function just forgets to add it to the spec file! 3) Generated functions This typically happens with widl: it generates a bunch of functions for the client / server and proxy cases, but these functions may be unused. I have special code to not warn about these, but there may be other cases. For instance in the list below you will find a number of yy*() functions generated by lex. Either we can tell lex to make them static or to not generate them, or I should make another special case. If you find some of these, let me know. 4) Assembly functions I believe there should not be any of these in the list below. So if you find one let me know. 5) Functions declared in a private header file but implemented and used from a single C file. I'm in favor of removing these functions from the private header and making them static. 6) All the others should be pretty clear-cut. dlls/advapi32/advapi32.dll.so: CRYPT_DESkey8to7 dlls/browseui/tests/browseui_test.exe.so: strdup_AtoW dlls/browseui/tests/browseui_test.exe.so: TestACL_ACList_AddRef dlls/browseui/tests/browseui_test.exe.so: TestACL_ACList_QueryInterface dlls/browseui/tests/browseui_test.exe.so: TestACL_ACList_Release dlls/browseui/tests/browseui_test.exe.so: TestACL_AddRef dlls/browseui/tests/browseui_test.exe.so: TestACL_Clone dlls/browseui/tests/browseui_test.exe.so: TestACL_Expand dlls/browseui/tests/browseui_test.exe.so: TestACL_Next dlls/browseui/tests/browseui_test.exe.so: TestACL_QueryInterface dlls/browseui/tests/browseui_test.exe.so: TestACL_Release dlls/browseui/tests/browseui_test.exe.so: TestACL_Reset dlls/browseui/tests/browseui_test.exe.so: TestACL_Skip dlls/cabinet/cabinet.dll.so: checksum dlls/cabinet/cabinet.dll.so: make_decode_table dlls/cabinet/cabinet.dll.so: QTMupdatemodel dlls/comctl32/tests/comctl32_test.exe.so: flush_sequence dlls/comdlg32/comdlg32.dll.so: CC_WMCommand dlls/crypt32/crypt32.dll.so: ContextList_Empty dlls/dbghelp/dbghelp.dll.so: hash_table_find dlls/dbghelp/dbghelp.dll.so: hash_table_hash dlls/dbghelp/dbghelp.dll.so: module_find_by_name dlls/dbghelp/dbghelp.dll.so: module_get_container dlls/dinput/dinput.dll.so: DIEnumDevicesCallbackAtoW dlls/dmime/dmime.dll.so: DMUSIC_CreateDirectMusicobjImpl dlls/dmime/dmime.dll.so: DMUSIC_CreateDirectMusicPatternTrackImpl dlls/dmusic/dmusic.dll.so: DMUSIC_CreateDirectMusicBufferImpl dlls/dmusic/dmusic.dll.so: DMUSIC_CreateDirectMusicDownloadedInstrumentImpl dlls/dmusic/dmusic.dll.so: DMUSIC_CreateDirectMusicDownloadImpl dlls/dnsapi/dnsapi.dll.so: dns_ns_name_pton dlls/dplayx/dplayx.dll.so: cbDeleteGroupsElem dlls/dplayx/dplayx.dll.so: cbDeletePlayerElem dlls/dplayx/dplayx.dll.so: DPLAYX_DestroyLobbyApplication dlls/dplayx/dplayx.dll.so: DPLAYX_SetLocalSession dlls/dplayx/dplayx.dll.so: NS_GetOtherMagic dlls/dplayx/dplayx.dll.so: NS_SetRemoteComputerAsNameServer dlls/dsound/dsound.dll.so: DirectSoundCaptureDevice_AddRef dlls/fusion/fusion.dll.so: assembly_get_architecture dlls/fusion/fusion.dll.so: CompareAssemblyIdentity dlls/fusion/fusion.dll.so: GetAssemblyIdentityFromFile dlls/inetcomm/inetcomm.dll.so: InternetTransport_Read dlls/iphlpapi/iphlpapi.dll.so: getInterfaceEntryByIndex dlls/iphlpapi/iphlpapi.dll.so: getInterfacePhysicalByName dlls/itss/itss.dll.so: chm_enumerate dlls/jscript/jscript.dll.so: jsdisp_call dlls/jscript/jscript.dll.so: parser_parse dlls/mountmgr.sys/mountmgr.sys.so: DriverEntry dlls/msacm32/msacm32.dll.so: MSACM_UnregisterLocalDriver dlls/mshtml/mshtml.dll.so: HTMLElementCollection_Create dlls/msi/msi.dll.so: cond_parse dlls/msi/msi.dll.so: ControlEvent_UnSubscribeToEvent dlls/msi/msi.dll.so: db_get_raw_stream dlls/msi/msi.dll.so: encode_streamname dlls/msi/msi.dll.so: find_published_source dlls/msi/msi.dll.so:
Re: [msvfw32/tests] Fix a test failure on W2K3
Hi Paul, You forgot to update the error messages. Christian Paul Vriens a écrit : Hi, Pick a compressor that's available on all platforms for this compressor type. Ideally we would use ICInfo to enumerate and pick one that's available but I think that's a bit too much for now. (This is the last one to fix the regressions in the conformance/regressions tests on my boxes from the last commit round ;) ) Changelog Fix a test failure on W2K3
qedit: tests/mediadet.c test skips sometimes
Hi, could anyone try the attached patch for the qedit test on a windows machine? It works around bug 16548. But according to the comment in the source I think this could be a mistake. I'd like to know if it works without renaming the file on windows. On wine it works. Cheers Rico diff --git a/dlls/qedit/tests/mediadet.c b/dlls/qedit/tests/mediadet.c index 2b43124..558ff3a 100644 --- a/dlls/qedit/tests/mediadet.c +++ b/dlls/qedit/tests/mediadet.c @@ -68,8 +68,10 @@ static BOOL unpack_avi_file(int id, WCHAR name[MAX_PATH]) return FALSE; DeleteFileW(name); +/* +Renaming isn't a good way to solve this, see bug 16548. lstrcpyW(name + lstrlenW(name) - 3, avi); - +*/ fh = CreateFileW(name, GENERIC_WRITE, 0, NULL, CREATE_NEW, FILE_ATTRIBUTE_NORMAL, NULL); if (fh == INVALID_HANDLE_VALUE)
Re: jscript: Do not call memcpy() with a NULL pointer argument
On Thu, Dec 18, 2008 at 2:21 PM, Andrew Talbot
andrew.tal...@talbotville.com wrote:
Changelog:
jscript: Do not call memcpy() with NULL pointer argument.
diff --git a/dlls/jscript/string.c b/dlls/jscript/string.c
index eeceb1f..b49d3b3 100644
--- a/dlls/jscript/string.c
+++ b/dlls/jscript/string.c
@@ -1395,8 +1395,12 @@ HRESULT create_string(script_ctx_t *ctx, const WCHAR
*str, DWORD len, DispatchEx
return E_OUTOFMEMORY;
}
-memcpy(string-str, str, len*sizeof(WCHAR));
-string-str[len] = 0;
+if (str) {
+memcpy(string-str, str, len*sizeof(WCHAR));
+string-str[len] = 0;
+}else {
+string-str[0] = 0;
+}
*ret = string-dispex;
return S_OK;
I didn't write jscript, so I'm not the expert, but create_string is
internal, so we should probably crash if str is NULL instead of hiding
the error. What is this patch for?
--
James Hawkins
Re: winecfg volume serial number
James Hawkins wrote: On Thu, Dec 18, 2008 at 12:31 PM, Michael Ost m...@museresearch.com wrote: wine-devel-requ...@winehq.org wrote: Date: Tue, 16 Dec 2008 13:52:00 +0100 From: Hoehle, Joerg-Cyril joerg-cyril.hoe...@t-systems.com Subject: winecfg volume serial number To: wine-devel@winehq.org Message-ID: 47cc5abb01651443a88db8ec5b4d657b01c8f...@s4de8psaank.mitte.t-com.de Content-Type: text/plain;charset=iso-8859-1 Hi, I just sent a bug-fix to wine-patches to prevent a crash in winecfg when editing the volume serial number input field, together with some unrelated thoughts about winecfg and the device/volume serial number handling. Then I realized that wine-patches is not a good place for discussion. So here are the ideas about winecfg's GUI: It doesn't make sense to me to rely on writing to a file to set the windows serial number or label. What about readonly disks? I think those values should be in the registry. Or at least check the registry should be a fallback if .windows-serial or .windows-label does not exist. I am stuck now because an installer program is looking for a CD of a certain label. I can't fudge in the label because it's a CD that I can't write to. Is anyone working on this issue, or agree/disagree? ... mo The label of the CD is read from the disk. If you're using a mounted ISO, you have to fix the access rights of the loopback file representing the ISO file. Yes, you are right. And this does work. In my system I am mounting a remote CD over samba and creating a drive letter for it in Wine. That's the disc that the installer wants to query. I was hoping to be able to set the label for the network drive to work around this issue. But the CD is read only so I can't write the file. So I am trying to do something tricky, that is probably not even possible in Windows. And I'll probably just have to my own internal Wine hack to get this to work. - mo
Re: winecfg volume serial number
On Thu, Dec 18, 2008 at 2:47 PM, Michael Ost m...@museresearch.com wrote: James Hawkins wrote: On Thu, Dec 18, 2008 at 12:31 PM, Michael Ost m...@museresearch.com wrote: wine-devel-requ...@winehq.org wrote: Date: Tue, 16 Dec 2008 13:52:00 +0100 From: Hoehle, Joerg-Cyril joerg-cyril.hoe...@t-systems.com Subject: winecfg volume serial number To: wine-devel@winehq.org Message-ID: 47cc5abb01651443a88db8ec5b4d657b01c8f...@s4de8psaank.mitte.t-com.de Content-Type: text/plain;charset=iso-8859-1 Hi, I just sent a bug-fix to wine-patches to prevent a crash in winecfg when editing the volume serial number input field, together with some unrelated thoughts about winecfg and the device/volume serial number handling. Then I realized that wine-patches is not a good place for discussion. So here are the ideas about winecfg's GUI: It doesn't make sense to me to rely on writing to a file to set the windows serial number or label. What about readonly disks? I think those values should be in the registry. Or at least check the registry should be a fallback if .windows-serial or .windows-label does not exist. I am stuck now because an installer program is looking for a CD of a certain label. I can't fudge in the label because it's a CD that I can't write to. Is anyone working on this issue, or agree/disagree? ... mo The label of the CD is read from the disk. If you're using a mounted ISO, you have to fix the access rights of the loopback file representing the ISO file. Yes, you are right. And this does work. In my system I am mounting a remote CD over samba and creating a drive letter for it in Wine. That's the disc that the installer wants to query. I was hoping to be able to set the label for the network drive to work around this issue. But the CD is read only so I can't write the file. So I am trying to do something tricky, that is probably not even possible in Windows. And I'll probably just have to my own internal Wine hack to get this to work. I don't understand the problem. If you have the proper permissions, wine should be able to read the volume name and everything should just work. What does volname give you for the network-mounted image? -- James Hawkins
Re: ntdll: fix a compiler warning on PC-BSD
2008/12/18 Austin English austinengl...@gmail.com: -- -Austin Ignore this patch, there are a few more I didn't notice. I'll update and resend. -- -Austin
Re: winecfg volume serial number
On Thu, Dec 18, 2008 at 3:07 PM, Michael Ost m...@museresearch.com wrote: Michael Karcher wrote: Am Donnerstag, den 18.12.2008, 14:53 -0800 schrieb James Hawkins: I don't understand the problem. If you have the proper permissions, wine should be able to read the volume name and everything should just work. What does volname give you for the network-mounted image? He is not mounting an image, but a mounted CD-ROM drive. Right. [m...@deceptor ~]$ mount (snip) //x.y.z.w/remotex on /home/most/.wine/drive_x type cifs (rw,mand) [m...@deceptor ~]$ ll ~/.wine/dosdevices/ total 0 lrwxrwxrwx 1 most most 10 2008-12-18 11:56 c: - ../drive_c lrwxrwxrwx 1 most most 10 2008-12-17 11:34 x: - ../drive_x GetVolumeInformation's CreateFile(.\\X:) call fails with status c034. So it tries get_filesystem_label, which tries to read //x.y.z.w/remotex/.windows-label via the symlinks. I can't write a file there so I can't fake in the label. My thought was to store the label in the registry and use that as a fallback if there is no .windows-label file. I'm all ears for alternate approaches though mo Have you tried setting the drive type to CD in winecfg? -- James Hawkins
Re: implicit declaration of function '_mkdir'
On Sun, Dec 14, 2008 at 5:29 AM, Gerald Pfeifer ger...@pfeifer.com wrote: I am mostly offline (2s ping times) for another two weeks, but noticed the following starting a couple of days ago on my nightly FreeBSD 6.4 tester: server.c:755: warning: implicit declaration of function '_mkdir' shellpath.c:2163: warning: implicit declaration of function '_mkdir' shfldr_unixfs.c:1745: warning: implicit declaration of function '_mkdir' xdg.c:253: warning: implicit declaration of function '_mkdir' theme.c:966: warning: implicit declaration of function '_mkdir' winemenubuilder.c:707: warning: implicit declaration of function '_mkdir' fd.c:1562: warning: implicit declaration of function '_mkdir' request.c:530: warning: implicit declaration of function '_mkdir' Perhaps one of you has an idea where this might come from and how to avoid it? Gerald http://bugs.winehq.org/show_bug.cgi?id=16561 I started to send a patch, then realized there a lot more occurrences, and didn't have time to fix them all. -- -Austin
RE: [PATCH] Fix ddraw surface version setting
The patch looks ok to me
RE: [PATCH] wined3d_gl.h minor typo fix
-USE_GL_FUNC(PGLFNGLFOGCOORDDVEXTPROC, glFogCoordvEXT, EXT_FOG_COORD, NULL )\ +USE_GL_FUNC(PGLFNGLFOGCOORDDVEXTPROC, glFogCoorddvEXT, EXT_FOG_COORD, NULL )\ I think I fixed that one with a patch in my glFogCoord emulation patchset a few days ago. Did you forget to update your git tree, or did I miss something? Other than that, the patch breaks the alignment of the 3rd and 4th column because a 'v' was added to the function name, but no space removed to keep the alignment.
RE: 4/4 WineD3D: add G16R16F / G32R32F support
I think we should emulate this format like we emulate R32F with ARGB32F if GL_TEXTURE_RG is not supported. It is a fairly new extension and the format is probably rather important. (It should not be part of this patch though. Just a general note, the patch itself looks ok) -Original Message- From: wine-patches-boun...@winehq.org [mailto:wine-patches- boun...@winehq.org] On Behalf Of Roderick Colenbrander Sent: Thursday, December 18, 2008 11:04 PM To: wine-patc...@winehq.org Subject: 4/4 WineD3D: add G16R16F / G32R32F support -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a
Re: Better user feedback and better user experience (idea)
Austin English wrote: On Thu, Dec 18, 2008 at 8:07 AM, Steve Brown sbro...@umbc.edu wrote: On Wed, 17 Dec 2008, Austin English wrote: In a few years when Wine is more developed and has most the API implemented, this may be useful, but there's still a lot to do, and we don't need more reports to tell us this. Keep in mind that the Windows API is a moving target. In a few years, the API will be no more completely implemented than it is today -- it will just be a different set of calls that aren't done than it is today. Steve Brown sbro...@umbc.edu Of course, didn't meant to imply that it will be complete at that time, but will be moreso than it is now, especially in regards to older API functions. I'm pretty sure we're catching up at this point. Wine development is getting faster, and the Windows API is changing slower - Microsoft does, after all, have to preserve backwards compatibility. So, it's fair to say that even with the release of Windows 7 Wine's implementation of the API will be more complete. Especially the API for running the apps we care about. Thanks, Scott Ritchie
Patch Feedback
Hi, Is there anything wrong with patches? [1/2] mshtml: Implement IHTMLScriptElement get/put event [2/2] mshtml: Implement IHTMLScriptElement get/put htmlFor Best Regards Alistair Leslie-Hughes
WCOM
Hi,all: I want support out-of-process COM on a mobile phone platform base on Linux. Wine is perfect,but also is too big and too complex to run on the device. So,I' going to create a project named WCOM with some code(ole32 and rpcrt4) from wine,well,WCOM is not need load by wine. I‘m a newbie and have a question: WCOM should be opensource,but the mobile phone platform is a business project, can i use the code from Wine to create WCOM without adding authorization from Wine or business license ? Best Regards faquir
Re: WCOM
can i use the code from Wine to create WCOM without adding authorization from Wine or business license ? Yes, but you must provide the source for your modified version of Wine to your customers. Read the LGPL for details. --Juan
re: WCOM
faquir wrote: I want support out-of-process COM on a mobile phone platform base on Linux. Wine is perfect,but also is too big and too complex to run on the device. So,I' going to create a project named WCOM with some code(ole32 and rpcrt4) from wine Say, how about making Wine configurable, like Embedded XP and Linux are? We already have a configure script. You could add a --tiny configure option to disable everything but the tiniest core needed for embedded devices. Avoiding a fork might be very good for you business-wise, because it would mean less maintenance work for you. Since Wine is LGPL, you are free to use it in commercial projects as long as you follow the license's requirements. Consult a lawyer for details. See also http://www.softwarefreedom.org/resources/2008/compliance-guide.html for a guide written by lawyers about how to conform to the GPL, LGPL, and related licenses. BTW, my take on things is: The intent of the LGPL was something like allow users to fix bugs in the code, so in general you should not static link Wine code directly into your apps, but rather leave Wine as replaceable dynamic shared libraries. You must provide the source for the Wine tree you use. Ideally you'd also provide a way for users to build Wine themselves and flash the device with their own improved versions of wine. But I Am Not A Lawyer. - Dan
Re: [3/5] wined3d: Only apply shader constants that changed.
Henri Verbeet wrote: This looks like data structure design mixed with GL and shader code. I think it would be better if the data structure was in its own file, without any GL or D3D dependencies, and wined3d and other components could use it. - Ivan
Re: WCOM
Thank you for your advices, I should read the LGPL more again. In WCOM, for performance, only ole32 and rptrt4 was remained and functions should be simplified , so many feature and code should be cutoff. There also is a runnable demo on windows :) BRs faquir Dan Kegel wrote: faquir wrote: I want support out-of-process COM on a mobile phone platform base on Linux. Wine is perfect,but also is too big and too complex to run on the device. So,I' going to create a project named WCOM with some code(ole32 and rpcrt4) from wine Say, how about making Wine configurable, like Embedded XP and Linux are? We already have a configure script. You could add a --tiny configure option to disable everything but the tiniest core needed for embedded devices. Avoiding a fork might be very good for you business-wise, because it would mean less maintenance work for you. Since Wine is LGPL, you are free to use it in commercial projects as long as you follow the license's requirements. Consult a lawyer for details. See also http://www.softwarefreedom.org/resources/2008/compliance-guide.html for a guide written by lawyers about how to conform to the GPL, LGPL, and related licenses. BTW, my take on things is: The intent of the LGPL was something like allow users to fix bugs in the code, so in general you should not static link Wine code directly into your apps, but rather leave Wine as replaceable dynamic shared libraries. You must provide the source for the Wine tree you use. Ideally you'd also provide a way for users to build Wine themselves and flash the device with their own improved versions of wine. But I Am Not A Lawyer. - Dan
Re: [3/5] wined3d: Only apply shader constants that changed.
2008/12/19 Ivan Gyurdiev ivg...@gmail.com: Henri Verbeet wrote: This looks like data structure design mixed with GL and shader code. I think it would be better if the data structure was in its own file, without any GL or D3D dependencies, and wined3d and other components could use it. If it was intended to be a generic heap, yes. However, this is intended to be specific to the GLSL shader backend. The main consideration there is that making it more generic would cost us performance which we can't afford, considering constant loading is the main bottleneck in most shader based applications.
