Temporary wine.git tree
Hi, Since Alexandre is lying on the beach in Greece and there'll be a gap between commits, I've made my Wine tree available and will be committing patches from wine-patches to it. You can pull (merge) these changes into your current Wine GIT tree it as follows: git fetch http://mandoo.dyndns.org/wine.git master:mmbranch git pull . mmbranch I'll send Alexandre a all the patches in the tree when he returns, but his tastes may differ to mine... :) Hopefully this will help prevent development from dropping to a snail's pace for two weeks. Mike
Re: First patch: Regedit Multi-String Value
Thanks a lot for the comments guys!
Here's a revised patch.. no more C++ style comments, no more inline
variable declarations and no more useless casting!
I think it should work pretty well.
I'll keep you updated with anything else I try soon as promised!
Philippe? patch-multistringvalue-1.1.diff
? programs/regedit_copy
? programs/regedit/patch-multistringvalue.diff
Index: programs/regedit/En.rc
===
RCS file: /home/wine/wine/programs/regedit/En.rc,v
retrieving revision 1.21
diff -u -p -r1.21 En.rc
--- programs/regedit/En.rc 26 Oct 2005 12:07:55 - 1.21
+++ programs/regedit/En.rc 26 Apr 2006 03:32:53 -
@@ -53,6 +53,7 @@ BEGIN
MENUITEM "&String Value", ID_EDIT_NEW_STRINGVALUE
MENUITEM "&Binary Value", ID_EDIT_NEW_BINARYVALUE
MENUITEM "&DWORD Value",ID_EDIT_NEW_DWORDVALUE
+MENUITEM "&Multi-String Value", ID_EDIT_NEW_MULTISTRINGVALUE
END
MENUITEM SEPARATOR
MENUITEM "&Delete\tDel",ID_EDIT_DELETE
@@ -129,6 +130,7 @@ BEGIN
MENUITEM "&String Value", ID_EDIT_NEW_STRINGVALUE
MENUITEM "&Binary Value", ID_EDIT_NEW_BINARYVALUE
MENUITEM "&DWORD Value",ID_EDIT_NEW_DWORDVALUE
+MENUITEM "&Multi-String Value", ID_EDIT_NEW_MULTISTRINGVALUE
END
MENUITEM SEPARATOR
MENUITEM "&Delete\tDel",ID_EDIT_DELETE
@@ -179,6 +181,7 @@ BEGIN
MENUITEM "&String Value", ID_EDIT_NEW_STRINGVALUE
MENUITEM "&Binary Value", ID_EDIT_NEW_BINARYVALUE
MENUITEM "&DWORD Value",ID_EDIT_NEW_DWORDVALUE
+MENUITEM "&Multi-String Value", ID_EDIT_NEW_MULTISTRINGVALUE
END
MENUITEM SEPARATOR
MENUITEM "&Delete\tDel",ID_EDIT_DELETE
@@ -258,6 +261,19 @@ BEGIN
PUSHBUTTON "Cancel",IDCANCEL,175,60,30,11,WS_GROUP
END
+IDD_EDIT_MULTISTRING DIALOG DISCARDABLE 22, 17, 210, 209
+STYLE DS_MODALFRAME | WS_CAPTION | WS_SYSMENU
+CAPTION "Edit String"
+FONT 8, "MS Shell Dlg"
+BEGIN
+LTEXT "Value name:",IDC_STATIC,5,5,119,8
+EDITTEXTIDC_VALUE_NAME,5,15,200,12, WS_BORDER | WS_TABSTOP | ES_AUTOHSCROLL| WS_DISABLED
+LTEXT "Value data:",IDC_STATIC,5,30,119,8
+EDITTEXTIDC_VALUE_DATA,5,40,200,144, WS_BORDER | WS_TABSTOP | WS_VSCROLL | WS_HSCROLL | ES_MULTILINE|ES_WANTRETURN
+DEFPUSHBUTTON "OK",IDOK,140,192,30,11,WS_GROUP
+PUSHBUTTON "Cancel",IDCANCEL,175,192,30,11,WS_GROUP
+END
+
IDD_EDIT_DWORD DIALOG DISCARDABLE 22, 17, 210, 100
STYLE DS_MODALFRAME | DS_NOIDLEMSG | WS_CAPTION | WS_SYSMENU
CAPTION "Edit DWORD"
@@ -317,11 +333,12 @@ END
STRINGTABLE DISCARDABLE
BEGIN
-ID_EDIT_MODIFY "Modifies the value's data"
-ID_EDIT_NEW_KEY "Adds a new key"
-ID_EDIT_NEW_STRINGVALUE "Adds a new string value"
-ID_EDIT_NEW_BINARYVALUE "Adds a new binary value"
-ID_EDIT_NEW_DWORDVALUE "Adds a new double word value"
+ID_EDIT_MODIFY "Modifies the value's data"
+ID_EDIT_NEW_KEY "Adds a new key"
+ID_EDIT_NEW_STRINGVALUE "Adds a new string value"
+ID_EDIT_NEW_BINARYVALUE "Adds a new binary value"
+ID_EDIT_NEW_DWORDVALUE "Adds a new double word value"
+ID_EDIT_NEW_MULTISTRINGVALUE "Adds a new multi-string value"
ID_REGISTRY_IMPORTREGISTRYFILE "Imports a text file into the registry"
ID_REGISTRY_EXPORTREGISTRYFILE
"Exports all or part of the registry to a text file"
Index: programs/regedit/edit.c
===
RCS file: /home/wine/wine/programs/regedit/edit.c,v
retrieving revision 1.20
diff -u -p -r1.20 edit.c
--- programs/regedit/edit.c 26 Oct 2005 12:07:55 - 1.20
+++ programs/regedit/edit.c 26 Apr 2006 03:32:53 -
@@ -242,6 +242,107 @@ done:
return NULL;
}
+/* This functions interpret a REG_MULTI_SZ element data to make it accessible within the GUI.
+ REG_MULTI_SZ is stored as a serie of NULL terminated strings, each of those strings
+ representing a single line. The list is terminated by an additionnal NULL character.
+ This function replaces the NULL terminators by new lines characters */
+/* Set 'toRegistryFormat' to 'TRUE' to convert from a list with strings separated by new line
+ characters to a list compromised of NULL terminated strings or false for the inverse
+ operation */
+/* 'len' is the length in bytes of the returned string */
+/* The returned string must be freed with HeapFree() once no more required! */
+TCHAR* convert_multistringvalue( BOOL toRegistryFormat, TCHAR* value, LONG *len )
+{
+int charcount = 0, newlinepos = 0, indexold = 0;
+int lenchar, lenbytes;
+BOOL newLine = FALSE; /* This variable is us
SambaXP update, part 2
Hi folks, now that SambaXP is officialy over, the samba team a couple of other people have retreated to a smaller room to discuss other things. Steve French had a talk about using CIFS on linux as a replacement to NFS which seems to be pretty cool. A couple of other talks were given, too, but if you're really interested, have a look at the schedule[1]. What was more interesting was that after the talks there was a panel discussion where the samba team expressed interest in continuing cooperation with Wine as discussed on last year's wineconf. Steve asked how exactly we wanted the named pipes exposed and if we could write up some testcases for that stuff. I think if anybody is interested in working on that is to email Steve directly. I got some more work on GENSEC done, but in order to really link this together, some more work is needed. I still have things blowing up on me when trying to use it for client-side sspi. Well, that's it for today, Kai [1] http://www.sambaxp.org/index.php?id=25 -- Kai Blin, (blin at gmx dot net) The star of riches is shining upon you.
Open Invention Network
Hello, I've just read an article on Linux Weekly News, which I guess might be interesting for Wine: http://lwn.net/Articles/178673/ (How Mono got into Fedora) I'll try to summarize: Basically, Novell bought Commerce One when they went bancrupt. Commerce One had some important patents related to XML webservices. Novell donated those to a newly formed organization called "Open Invention Network". OIN gives royalty free licences to companys and individuals who agree not to sue certain open source projects for violating their patents in turn. (http://openinventionnetwork.com/pat_linuxdefpop.html - Wine is currently not on the list). The interesting thing is the following. If a project, which is on this list, is sued for patent infringment, then it is allowed to use the OIN patents in a countersuit. I hope this isn't old news. Perhaps Wine should apply to get on OIN's "Linux definition" list? Bye, -- Michael Jung [EMAIL PROTECTED]
Re: riched20: Implement EM_SETUNDOLIMIT and its conformance tests, take 2
On Wed, April 26, 2006 1:30 pm, Matt Finnicum said: > I welcome your comments on the patch. Minor nits: -- how about 2 constants for the values 100, 1000 #define STACK_SIZE_DEFAULT 100 #define STACK_SIZE_MAX 1000 -- maybe use min(wParam, STACK_SIZE_MAX) when setting it -- Dimi Paun <[EMAIL PROTECTED]> Lattica, Inc.
Re: setupapi: Fix parsing of UCS-16 files
Am Mittwoch, den 26.04.2006, 15:42 +0100 schrieb Robert Shearman: > +if (*new_buff == 0xfeff) > +new_buff++; > .. new_buff, (WCHAR *)((char*)new_buff +size), error_line ); This points behind the End of the File-Mapping, when you skip the BOM. The Pointer to the End of the Data is still: (WCHAR *)((char*)buffer+size -- By By ... ... Detlef
Re: Just want to make a comment about the current status of the project
On 4/25/06, Philip V. Neves <[EMAIL PROTECTED]> wrote: > I've been really looking at wine for the last couple of months or so. > Last little bit I've been helping by doing some testing and filing bug > reports. I must say the developers of this project have done an amazing > job. Its increadible how close you all are. If you can at least get > code associated with making install shield based installers and other > installers work flawlessly in the next little while this project will > set the being a major thorn in Microsofts side when they bring out > Vista. This project has the potential to really deflate them. If > anything could be a major encouragement to you this no doubt should be. Ummm... they're not trying to be a thorn in Microsoft's side so much as simply interoperate with them. Think compatibility. The kind that opens markets, creates options, and encourages diversity. If Microsoft can't survive in such an environment, it's their doing. Not ours. --tim
Re: [SOC] ASIO
Hi Tom, On Tuesday 25 Apr 2006 19:05, Tom Spear wrote: > On 4/25/06, Paul Millar <[EMAIL PROTECTED]> wrote: > > Yes, this looks to be amenable to a clean-room implementation. [...] > > I don't see any reason why that couldn't work. We could combine that test > suite with users that use various pro-audio apps tests of said apps. For > example, some users prefer fruity loops over soundforge or acid, but we can > test all 3 against the implementation, modify (or initially write) the > tests to do the same things as these apps, and then build the > implementation based on the tests.. Yes, one option is to use applications to do the testing. Another is to write discrete functional tests against each part of the API (c.f. the wine test framework). Both approaches have pros and cons. I was thinking more the wine test framework in mind. Assuming we use wine test, part of the "contaminated" student's job would be to write a set of tests (presumably with loads of todo_wine ok()s to begin with :). These tests would hopefully "cover" all the documented expected behaviour. As a bonus, writing the tests through wine test means it could be fairly easily tested what we (and presumably the SDK) thinks is correct behaviour against the various (close-source) implementations. The "clean" student would implement code and remove the "todo_wine" bit as she proceeds. > Not to go off topic, but that might be a good method (now that I think > about it) to find out what various other apps do.. Sure it is the same as > making a testcase, but in this case, we are working backwards, which might > speed up patch production in some cases > > If I am reading what you said above, you basically want to for example, > take fruity loops, figure out what it does when you do various things (by > tracing that app's execution), then using that trace, write our own code to > produce an _identical_ trace, and then use that code to make patches to > other areas of wine.. At the risk of pointing out what may be obvious, what you describe here is (one element of) reverse engineering rather than a clean-room method. Yeah, you can do reverse engineering to figure out the *actual* behaviour, but: 1. its (probably) slower that doing a proper clean-room implementation, 2. you'd inherit any "bugs" from your applications, 3. you (probably) won't cover all the functionality. Some new app. might come along that wine won't support, On the plus side you see how applications are *actually* using the API (hence can support broken or illdefined behaviour, if the app needs it). > Am I off the mark here? If not that really could help out our release > cycle, and increase the number of bugs fixed per release. Its horses for courses. Some of wine comes from applications not working, which is subsequently traced back to some undocumented behaviour in Windows. But, given the information available in the SDK, it would be a shame not to use it if we can. Cheers, Paul. pgpL03KPFY7H8.pgp Description: PGP signature
Just want to make a comment about the current status of the project
I've been really looking at wine for the last couple of months or so. Last little bit I've been helping by doing some testing and filing bug reports. I must say the developers of this project have done an amazing job. Its increadible how close you all are. If you can at least get code associated with making install shield based installers and other installers work flawlessly in the next little while this project will set the being a major thorn in Microsofts side when they bring out Vista. This project has the potential to really deflate them. If anything could be a major encouragement to you this no doubt should be. Thanx guys.
Re: [Wine] Support section revamp
Thanks. I love it. I'm on a dial-in system and have an RSS feed for comp.emulators.ms-windows.wine via Google Groups on my pim. Imagine the delight when I saw the feed included the wine-users mailing list messages. This is perfect. The fewer places I have to go on-line to get information that I or others may need means the faster I can get back to my very busy real life off-line. Being able to dial-in and glance at my pim is about as easy and fast as it gets. Thank you. deedee On Tuesday 25 April 2006 02:08 pm, Jeremy White wrote: > We've now reconnected the newgroup > comp.emulators.ms-windows.wine to the wine-users mailing list, > so they are, in theory, one 'virtual' community. -- Registered Linux User #327485
