Re: Fix NtAccessCheck so it works with relative SECURITY_DESCRIPTORs
Evan Deaubl wrote:
ChangeLog:
* Fix NtAccessCheck so it works with relative SECURITY_DESCRIPTORs
I cleaned up the patch a little. Does this still work for you?
Changelog:
Evan Deaubl <[EMAIL PROTECTED]>
Robert Shearman <[EMAIL PROTECTED]>
- Implement RtlGetControlSecurityDescriptor
- Fix NtAccessCheck so it works with relative SECURITY_DESCRIPTORs
--
Rob Shearman
Index: dlls/ntdll/sec.c
===
RCS file: /home/wine/wine/dlls/ntdll/sec.c,v
retrieving revision 1.52
diff -u -p -r1.52 sec.c
--- dlls/ntdll/sec.c 24 May 2005 12:32:19 - 1.52
+++ dlls/ntdll/sec.c 31 May 2005 06:47:20 -
@@ -831,6 +831,27 @@ NTSTATUS WINAPI RtlSelfRelativeToAbsolut
return status;
}
+/**
+ * RtlGetControlSecurityDescriptor (NTDLL.@)
+ */
+NTSTATUS WINAPI RtlGetControlSecurityDescriptor(
+PSECURITY_DESCRIPTOR pSecurityDescriptor,
+PSECURITY_DESCRIPTOR_CONTROL pControl,
+LPDWORD lpdwRevision)
+{
+SECURITY_DESCRIPTOR* lpsd=pSecurityDescriptor;
+
+TRACE("(%p,%p,%p),stub!\n",pSecurityDescriptor,pControl,lpdwRevision);
+
+if ( !lpsd || !pControl || !lpdwRevision )
+return STATUS_INVALID_PARAMETER;
+
+*lpdwRevision = lpsd->Revision;
+*pControl = lpsd->Control;
+
+return STATUS_SUCCESS;
+}
+
/**
* RtlAbsoluteToSelfRelativeSD [EMAIL PROTECTED]
@@ -1197,7 +1218,13 @@ NtAccessCheck(
SERVER_START_REQ( access_check )
{
struct security_descriptor sd;
-const SECURITY_DESCRIPTOR * RealSD = (const SECURITY_DESCRIPTOR *)SecurityDescriptor;
+PSID owner;
+PSID group;
+PACL sacl;
+PACL dacl;
+BOOLEAN defaulted, present;
+DWORD revision;
+SECURITY_DESCRIPTOR_CONTROL control;
req->handle = ClientToken;
req->desired_access = DesiredAccess;
@@ -1207,16 +1234,22 @@ NtAccessCheck(
req->mapping_all = GenericMapping->GenericAll;
/* marshal security descriptor */
-sd.control = RealSD->Control;
-sd.owner_len = RtlLengthSid( RealSD->Owner );
-sd.group_len = RtlLengthSid( RealSD->Group );
-sd.sacl_len = (RealSD->Sacl ? RealSD->Sacl->AclSize : 0);
-sd.dacl_len = (RealSD->Dacl ? RealSD->Dacl->AclSize : 0);
+RtlGetControlSecurityDescriptor( SecurityDescriptor, &control, &revision );
+sd.control = control & ~SE_SELF_RELATIVE;
+RtlGetOwnerSecurityDescriptor( SecurityDescriptor, &owner, &defaulted );
+sd.owner_len = RtlLengthSid( owner );
+RtlGetGroupSecurityDescriptor( SecurityDescriptor, &group, &defaulted );
+sd.group_len = RtlLengthSid( group );
+RtlGetSaclSecurityDescriptor( SecurityDescriptor, &present, &sacl, &defaulted );
+sd.sacl_len = (present ? sacl->AclSize : 0);
+RtlGetDaclSecurityDescriptor( SecurityDescriptor, &present, &dacl, &defaulted );
+sd.dacl_len = (present ? dacl->AclSize : 0);
+
wine_server_add_data( req, &sd, sizeof(sd) );
-wine_server_add_data( req, RealSD->Owner, sd.owner_len );
-wine_server_add_data( req, RealSD->Group, sd.group_len );
-wine_server_add_data( req, RealSD->Sacl, sd.sacl_len );
-wine_server_add_data( req, RealSD->Dacl, sd.dacl_len );
+wine_server_add_data( req, owner, sd.owner_len );
+wine_server_add_data( req, group, sd.group_len );
+wine_server_add_data( req, sacl, sd.sacl_len );
+wine_server_add_data( req, dacl, sd.dacl_len );
wine_server_set_reply( req, &PrivilegeSet->Privilege, *ReturnLength - FIELD_OFFSET( PRIVILEGE_SET, Privilege ) );
@@ -1244,19 +1277,6 @@ NtSetSecurityObject(
IN PSECURITY_DESCRIPTOR SecurityDescriptor)
{
FIXME("%p 0x%08lx %p\n", Handle, SecurityInformation, SecurityDescriptor);
- return STATUS_SUCCESS;
-}
-
-/**
- * RtlGetControlSecurityDescriptor (NTDLL.@)
- */
-
-NTSTATUS WINAPI RtlGetControlSecurityDescriptor(
- PSECURITY_DESCRIPTOR pSecurityDescriptor,
- PSECURITY_DESCRIPTOR_CONTROL pControl,
- LPDWORD lpdwRevision)
-{
- FIXME("(%p,%p,%p),stub!\n",pSecurityDescriptor,pControl,lpdwRevision);
return STATUS_SUCCESS;
}
Re: tab: Shift selected tab text up instead of down [RESEND]
+if (iItem == infoPtr->iSelected) +center_offset_v = ((drawRect->bottom - drawRect->top) - (rcText.bottom - rcText.top) - infoPtr->uVItemPadding) / 2; +else +center_offset_v = ((drawRect->bottom - drawRect->top) - (rcText.bottom - rcText.top) + infoPtr->uVItemPadding) / 2; Wouldn't it be clearer as: center_offset_v = (drawRect->bottom - drawRect->top) + (rcText.bottom - rcText.top); if (iItem == infoPtr->iSelected) center_offset_v -= infoPtr->uVItemPadding; else center_offset_v += infoPtr->uVItemPadding; center_offset_v /= 2; That breaks up the long lines, and eliminates the common sub-expressions... Mike
Re: ntdll.dll: mark dirlink as REPARSE_POINT (v2)
On Tue, 2005-05-31 at 06:21 +0200, Detlef Riekenberg wrote:
> -if (S_ISDIR( st.st_mode ) && !show_dir_symlinks) return NULL;
> +if (S_ISDIR( st.st_mode ))
> + {
> + if (!show_dir_symlinks) return NULL;
> + name_is_link = FILE_ATTRIBUTE_REPARSE_POINT;
> + }
> }
Hmm, thinking more about it, if windows has support for dir symlinks
(I'm sure they made sure there are no problems with that), should we
even bother having this show_dir_symlinks option? Maybe we should just
nuke it, and just have:
if (S_ISDIR( st.st_mode )) name_is_link = FILE_ATTRIBUTE_REPARSE_POINT;
On a different note, are the brackets above indented properly?
--
Dimi Paun <[EMAIL PROTECTED]>
Lattica, Inc.
ntdll.dll: mark dirlink as REPARSE_POINT (v2)
Changelog:
Mark links to dir with "FILE_ATTRIBUTE_REPARSE_POINT",
so modern Applications can use this additional Information.
Supported by ntdll.dll since win2000.
(Application as Example: totalcmd.exe >6.50)
v2: Reformatted as suggested by Dimi Paun
--
By By ...
... Detlef
Index: dlls/ntdll/directory.c
===
RCS file: /home/wine/wine/dlls/ntdll/directory.c,v
retrieving revision 1.29
diff -u -r1.29 directory.c
--- dlls/ntdll/directory.c 30 May 2005 11:33:42 - 1.29
+++ dlls/ntdll/directory.c 31 May 2005 04:17:08 -
@@ -722,6 +722,7 @@
WCHAR long_nameW[MAX_DIR_ENTRY_LEN];
WCHAR short_nameW[12];
UNICODE_STRING str;
+ULONG name_is_link=0;
long_len = ntdll_umbstowcs( 0, long_name, strlen(long_name), long_nameW, MAX_DIR_ENTRY_LEN );
if (long_len == -1) return NULL;
@@ -766,7 +767,11 @@
if (S_ISLNK( st.st_mode ))
{
if (stat( long_name, &st ) == -1) return NULL;
-if (S_ISDIR( st.st_mode ) && !show_dir_symlinks) return NULL;
+if (S_ISDIR( st.st_mode ))
+ {
+ if (!show_dir_symlinks) return NULL;
+ name_is_link = FILE_ATTRIBUTE_REPARSE_POINT;
+ }
}
info->NextEntryOffset = total_len;
@@ -780,7 +785,7 @@
if (S_ISDIR(st.st_mode))
{
info->EndOfFile.QuadPart = info->AllocationSize.QuadPart = 0;
-info->FileAttributes = FILE_ATTRIBUTE_DIRECTORY;
+info->FileAttributes = (FILE_ATTRIBUTE_DIRECTORY | name_is_link) ;
}
else
{
Re: wine/dlls/x11drv keyboard.c
"Francois Gouget" <[EMAIL PROTECTED]> wrote: > > Fix Estonian keyboard layout to better match the X11 one. > > I have noticed that we get a steady trickle of these. Shouldn't it be > possible to get the definitions of all keyboards from the XFree sources > and find some way to automatically import them? Probably. But actually I need to find some time and fix the source of the problem: fill keyc2vkey and keyc2scan tables with actual data reported by X11, not values from hardcoded keyboard layouts. -- Dmitry.
generic.ppd isn't installed anymore
Hi, wineps/generic.ppd isn't installed anymore since a couple weeks ago (didn't had time yet to pinpoint exact patch). I think it's because only __install-lib__ and __install-dev__ is done in dlls/ now, and not __install__, which is the target actually installing wineps/generic.ppd. A quick'n dirty way is to run make -C dlls/wineps install after make install but it should really be fixed properly I guess. Vincent
Re: [Fwd: Re: Extending File Dialog to include unix file paths]
Hi Alexandre, I haven't got a reply from you on this issue yet. Please let me know what you think of the patch. Thanks, Michael Michael Lin wrote: Hi Alexandre, I have made the changes as you suggested to put all the entry point in one single library. Basically, I have created a new library called wineunixfs. It currently contain modified version of filedlg.c and filedlgbrowser.* and all their dependent files from commdlg. I have attached the diff file for the rest of the changes that's on the core libraries. I didn't attach the files in wineunixfs as you seems ok with duplicating code there and modify it there. Most of the changes are contained within shell32 libraries to make it aware of whether it is in unix or dos path mode. There is only one exported function been added and that is SHUnixFSGetDesktopFolder() in shell32. Could you please take a look at the patch and let me know if this is "clean" and acceptable. Thanks, Michael
Re: Borland C++ 4.5
On Tue, 31 May 2005 06:12, Andrew Neil Ramage wrote: > When I tried to install BC++ 4.5, the installation proceeded normally. > However, when I clicked "Finish", it trashed my X server, causing the > system to stop responding to key presses and the mouse. I could not > even kill the X server, and so had to pull the power cord out. Is this > a known problem, and will I still be able to use my Development identity ? There probably aren't many people still using BC++4.5, but those that do don't particularly care about this problem. If you copy over your bc45 directory from a native Windows installation it should just work(tm).
Re: ntdll.dll: mark dirlink as REPARSE_POINT
On Tue, 2005-05-31 at 00:00 +0200, Detlef Riekenberg wrote:
> -if (S_ISDIR( st.st_mode ) && !show_dir_symlinks) return NULL;
> +if (S_ISDIR( st.st_mode ))
> + {
> + if (!show_dir_symlinks)
> + {
> + return NULL;
> + }else
> + {
> + name_is_link = FILE_ATTRIBUTE_REPARSE_POINT;
> + }
> + }
Minor point, but it would be more in the Wine style to code above as:
+if (S_ISDIR( st.st_mode ))
+{
+if (!show_dir_symlinks) return NULL;
+name_is_link = FILE_ATTRIBUTE_REPARSE_POINT;
+}
--
Dimi Paun <[EMAIL PROTECTED]>
Lattica, Inc.
Borland C++ 4.5
When I tried to install BC++ 4.5, the installation proceeded normally. However, when I clicked "Finish", it trashed my X server, causing the system to stop responding to key presses and the mouse. I could not even kill the X server, and so had to pull the power cord out. Is this a known problem, and will I still be able to use my Development identity ? -- Andrew You can be the captain I will draw the chart Sailing into destiny Closer to the heart Closer to the Heart by Rush (A Farewell to Kings, 1977) ~
Re: OLEAUT32 (resend) Floating point locale, no negative zero
Alexandre Julliard wrote: Alex Villacis Lasso <[EMAIL PROTECTED]> writes: Changelog: * Force Single|Double conversion to BSTR to use the decimal separator defined by the current locale, because that is what native oleaut32 does, and to be consistent with later parsing of floating-point numbers, which uses current locale. Failure to apply this patch causes vartype test to fail in non-US locales with a decimal separator other than a period. * The number form "-0" is *not* allowed to be returned in a Single|Double conversion to BSTR in case of numeric undeflow, use unsigned zero instead. Some applications depend on this. Test included. That's ugly, I think we really want to do our own formatting instead of using the system printf and hacking the string afterwards. By "our own formatting", do you mean to reimplement the %f and %lf functionality of the system printf() in a Wine-specific function? It can be done, of course, but I thought there was a good reason for the original code to rely on the system printf() for the floating-point formatting. Then there is the question of whether the potential patch is still allowed to use GetNumberFormatW for the (dwFlags & LOCALE_USE_NLS) case. This function seems to relay on the decimal separator being a period (as built by sprintfW). A more recent patch I sent used GetNumberFormatW for the non-NLS case to achieve the substitution of the period for whatever the decimal separator was in the current locale. However, GetNumberFormatW() cannot do anything about the negative zero issue, so that was still handled in the VARIANT_BstrFromReal() function of vartype.c. How much formatting should the new formatting function do? Is it enough to handle the negative zero and the decimal separator, and use sprintfW() for the LOCALE_USE_NLS case (as the current code does), or does it have to reimplement the functionality currently delegated to GetNumberFormatW()? I will start making a patch assuming the first scenario (use new function just for non-NLS case). Please answer if anybody thinks it should be done otherwise. Alex Villacís Lasso
Re: wine/dlls/x11drv keyboard.c
On Mon, 30 May 2005 11:14:01 +0200 (CEST), you wrote: > The other trickle we're seeing is with timezones. So in a similar way > maybe we could get the data from the site below and import it all: > http://www.timeanddate.com/library/abbreviations/timezones/ That is a very limited number of timezone abbreviations. You should use go for the timezone data in ftp://elsie.nci.nih.gov/pub/tzdata*.tar.gz which is the source for the timezone data in Linux, *BSD and probably others. I am working to get this data - as far as Window's limited timezone information allows - converted. That means that in Wine there will be a same timezones (e.g. Europe/Amsterdam) as under Linux including the daylight saving transition times. Rein.
Re: CryptUnprotectData undeclared - cannot compile
Works fine for me - I use the attached scripts. Andrew You can be the captain I will draw the chart Sailing into destiny Closer to the heart Closer to the Heart by Rush (A Farewell to Kings, 1977) ~ Pavel Troller wrote: Hello, have you done a cvs update -Pd ? Hello, of course, it's in my .cvsrc . cvs doesn't show any M'ed nor C'ed files, the update is clean. I also did a make clean in dlls, as suggested by Mike, but the problem is still there. Of course I know a standard procedure of ./configure ; make depend && make and I'm always following it. Now I'm trying 'make distclean' before anything else... Yes, the problem is still there. Now I'm posting all the output from crypt32: make[2]: Entering directory `/usr/src/emul/wine/dlls/crypt32' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_CRYPT32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o cert.o cert.c gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_COMCTL32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o commctrl.o commctrl.c gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_CRYPT32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o encode.o encode.c gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_CRYPT32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o protectdata.o protectdata.c gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_COMCTL32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o datetime.o datetime.c gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_CRYPT32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o main.o main.c ../../tools/winebuild/winebuild -D__WINESRC__ -D_CRYPT32_ -o crypt32.dll.dbg.c --debug -C. cert.c encode.c protectdata.c main.c make[3]: Entering directory `/usr/src/emul/wine/dlls/crypt32/tests' gcc -c -I. -I. -I../../../include -I../../../include-D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o protectdata.o protectdata.c gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_COMCTL32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o draglist.o draglist.c gcc -c -I. -I. -I../../../include -I../../../include-D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o testlist.o testlist.c gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_COMCTL32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o flatsb.o flatsb.c ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole protectdata.o testlist.o -o crypt32_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../dlls/crypt32 -L../../../libs -lcrypt32 -s -L/opt/ungif/lib gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_COMCTL32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o header.o header.c protectdata.o(.text+0x3b5): In function `test_cryptunprotectdata': /usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:114: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x42f):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:120: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x4b9):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:129: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x54f):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:140: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x702):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:160: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x782):/usr/src/emul/wine/dlls/crypt32/tests
Hint for Wine + Type1 + FrameMaker / Update for the Font HOWTO
Hi Avi, Having spend endless hours looking for how to make Wine and Type1 fonts working together. I finally decided to convert my Type1 fonts to Truetype (after a hint by someone that Wine does not have Type1/Adobe support). Note: I'm not sure if this is true since there is a wine [afmdirs] section in the wine config. Wine still had troubles with (at least) some of the files. Converting Type1 fonts to Truetype fonts was easy and Framemaker actually has a hidden feature to find out which fonts are missing. When you load your FrameMaker document and you have missing fonts, it wants to reformat your file. After you allow that, just look at the available fonts, suddenly you have a few extra ones in the list that have been disabled. These are the fonts FrameMaker requires and couldn't find. Note down the names as they appear in the list, quit the document without saving (!), then go look for the Type1 fonts that match the name using grep. Open them in fontforge (http://fontforge.sourceforge.net/), if necessary change the Family Name to what you wrote down and safe it as a Truetype font. If you do that for all the files involved, everything works fine. I added this explanation to my document bits (for google) http://dag.wieers.com/howto/bits/wine-framemaker-type1.php So fontforge should definitely be part of the Font HOWTO and maybe something about Wine and Type1 support (and FrameMaker) too ? PS I included the Wine list too, as I looked there for answers first. I bet some more people will do the same and come across this thread. Hope this helps and thanks for a great resource, -- dag wieers, [EMAIL PROTECTED], http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Re: UT2003 Regression - Patch at last :-))
On Thu, 26 May 2005 22:06:30 +0200, Alexandre Julliard wrote: > Alexandre Julliard <[EMAIL PROTECTED]> writes: > >> "Ann and Jason Edmeades" <[EMAIL PROTECTED]> writes: >> >> > What about instead of the send_ncpaind/send_erase when child==prev >> > (assuming >> > this to be the more 'unusual' case and not the norm) I build a list of the >> > hwnds and validate their update region. When the loop completes, for each >> > hwnd left in the list I do the send_ncpaint/send_erase processing? >> > >> > Without removing the update region there's no way to step further in the >> > list, if I understand the problem correctly? >> >> Yes, but that's what needs to be fixed, we need to make progress even >> if the update region is not validated. We will then get a WM_PAINT in >> the main message loop, which I believe is what we want. > > Try something like this: [snip patch] Thanks for that! I just thought I'd mention that this also fixes problems with Transport Tycoon Deluxe, another game that had a blank window and put wine in an infinite loop since the changes from 2004-12-07. With this patch it works again, so it'd be great if this could make it into CVS soon. Thanks again! -- Josef Drexler | http://jdrexler.com/home/ -+--- Please help Conserve Gravity| Email address is *valid*. Play Chess, not Basketball. | Don't remove the "nospam" part.
Re[2]: tab: Shift selected tab text up instead of down
Monday, May 30, 2005, 1:20:31 AM, you wrote: > On 5/29/05, Vitaliy Margolen <[EMAIL PROTECTED]> wrote: >> Sunday, May 29, 2005, 2:17:12, Vitaliy Margolen wrote: >> > Hi, >> >> > Changelog >> > * Shift selected tab text up instead of down. >> >- drawRect->>bottom += 3; >> >+ drawRect->>bottom -= 3; >> >> This does not shift tab up. > The location of the tab stays the same. The text is shifted up. I'm not talking about tab itself. But interior of the tab. Selected tab interior is 3 pixels bigger then none selected one. Here is a test app I'm using to test this things: http://www.kievinfo.com/Tab_size.tar.bz2 It displays all kinds of tabs and prints tab dimensions for owner drawn once to stdout. It's a Delphi app so if you want to modify it you'll need Delphi to compile it. This test clearly shows you patch is incorrect. Vitaliy
Re: CryptUnprotectData undeclared - cannot compile
Pavel Troller wrote: solution is to: cd dlls rm *.def cd .. make Ciao, Marcus Hi Marcus, yes, Your solution is the Right One! Thanks! However, I think that something is wrong with make distclean, because it should erase all the generated files including these .def's ? Or is there a reason to keep them in (and possibly cause problems) ? No, the problem is the make system changed and those .def's are needed anymore and also not generated anymore. There is no reason for make [dist]clean to get rid of them. That's why i love out of source tree builds: rm -rf on the wine build tree is a very good 'make realyclean' command ;) bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Re: CryptUnprotectData undeclared - cannot compile
On Mon, May 30, 2005 at 03:23:13PM +0200, Pavel Troller wrote: > > solution is to: > > > > cd dlls > > rm *.def > > cd .. > > make > > > > Ciao, Marcus > > Hi Marcus, > yes, Your solution is the Right One! Thanks! > However, I think that something is wrong with make distclean, because it > should erase all the generated files including these .def's ? Or is there > a reason to keep them in (and possibly cause problems) ? You need to run "make distclean" BEFORE doing cvs update, this would have avoided it I guess. This is just a temporary hickup. Ciao, Marcus pgpgkp0QlC3Hs.pgp Description: PGP signature
Re: CryptUnprotectData undeclared - cannot compile
> solution is to: > > cd dlls > rm *.def > cd .. > make > > Ciao, Marcus Hi Marcus, yes, Your solution is the Right One! Thanks! However, I think that something is wrong with make distclean, because it should erase all the generated files including these .def's ? Or is there a reason to keep them in (and possibly cause problems) ? With regards, Pavel Troller
Re: CryptUnprotectData undeclared - cannot compile
On Mon, May 30, 2005 at 02:40:20PM +0200, Michael Stefaniuc wrote: > Hello, > > have you done a cvs update -Pd ? No, solution is to: cd dlls rm *.def cd .. make Ciao, Marcus pgpjWr4xGk8eg.pgp Description: PGP signature
Re: CryptUnprotectData undeclared - cannot compile
> Hello, > > have you done a cvs update -Pd ? > Hello, of course, it's in my .cvsrc . cvs doesn't show any M'ed nor C'ed files, the update is clean. I also did a make clean in dlls, as suggested by Mike, but the problem is still there. Of course I know a standard procedure of ./configure ; make depend && make and I'm always following it. Now I'm trying 'make distclean' before anything else... Yes, the problem is still there. Now I'm posting all the output from crypt32: make[2]: Entering directory `/usr/src/emul/wine/dlls/crypt32' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_CRYPT32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o cert.o cert.c gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_COMCTL32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o commctrl.o commctrl.c gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_CRYPT32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o encode.o encode.c gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_CRYPT32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o protectdata.o protectdata.c gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_COMCTL32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o datetime.o datetime.c gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_CRYPT32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o main.o main.c ../../tools/winebuild/winebuild -D__WINESRC__ -D_CRYPT32_ -o crypt32.dll.dbg.c --debug -C. cert.c encode.c protectdata.c main.c make[3]: Entering directory `/usr/src/emul/wine/dlls/crypt32/tests' gcc -c -I. -I. -I../../../include -I../../../include-D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o protectdata.o protectdata.c gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_COMCTL32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o draglist.o draglist.c gcc -c -I. -I. -I../../../include -I../../../include-D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o testlist.o testlist.c gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_COMCTL32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o flatsb.o flatsb.c ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole protectdata.o testlist.o -o crypt32_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../dlls/crypt32 -L../../../libs -lcrypt32 -s -L/opt/ungif/lib gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_COMCTL32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -I/opt/ungif/include -I/opt/ungif/include -O2 -march=i586 -mcpu=i586 -o header.o header.c protectdata.o(.text+0x3b5): In function `test_cryptunprotectdata': /usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:114: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x42f):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:120: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x4b9):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:129: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x54f):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:140: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x702):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:160: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x782):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:167: more undefined references to `CryptUnprotectData' follow collect2: ld returned 1 exit status So, still no luck. With regards, Pavel Troller
Re: CryptUnprotectData undeclared - cannot compile
Hello, have you done a cvs update -Pd ? bye michael Pavel Troller wrote: For some time, about 10 - 14 days, I cannot compile wine from CVS anymore. The reason is as follows: make[3]: Entering directory `/usr/src/emul/wine/dlls/crypt32/tests' ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole protectdata.o testlist.o -o crypt32_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../dlls/crypt32 -L../../../libs -lcrypt32 -s -L/opt/ungif/lib protectdata.o(.text+0x3b5): In function `test_cryptunprotectdata': /usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:114: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x42f):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:120: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x4b9):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:129: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x54f):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:140: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x702):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:160: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x782):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:167: more undefined references to `CryptUnprotectData' follow collect2: ld returned 1 exit status The same reported another user on the user's list, but nobody noticed it. It would be nice to fix this problem to be able to compile wine again. With regards, Pavel Troller -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
CryptUnprotectData undeclared - cannot compile
Hi! For some time, about 10 - 14 days, I cannot compile wine from CVS anymore. The reason is as follows: make[3]: Entering directory `/usr/src/emul/wine/dlls/crypt32/tests' ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole protectdata.o testlist.o -o crypt32_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../dlls/crypt32 -L../../../libs -lcrypt32 -s -L/opt/ungif/lib protectdata.o(.text+0x3b5): In function `test_cryptunprotectdata': /usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:114: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x42f):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:120: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x4b9):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:129: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x54f):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:140: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x702):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:160: undefined reference to `CryptUnprotectData' protectdata.o(.text+0x782):/usr/src/emul/wine/dlls/crypt32/tests/protectdata.c:167: more undefined references to `CryptUnprotectData' follow collect2: ld returned 1 exit status The same reported another user on the user's list, but nobody noticed it. It would be nice to fix this problem to be able to compile wine again. With regards, Pavel Troller
Re: [DSOUND]multiple DIRECTSOUND object support
Robert Reif <[EMAIL PROTECTED]> writes: > Add multiple DIRECTSOUND object support (multiple sound cards can play > at the same time). > Fix CoCreateInstance when no sound card is present. > Fix create bug found by Mike Hearn. This is causing major trouble with make test for me: ../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so ds3d.c && touch ds3d.ok wine: Unhandled exception (thread 003c), starting debugger... WineDbg starting on pid 0x3a Unhandled exception: page fault on read access to 0x88d9a3d0 in 32-bit code (0x779a6b3b). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:779a6b3b ESP:7292809c EBP:729280ac EFLAGS:00010a13( - 00 ROIA1C) EAX:11154d54 EBX:779bfc58 ECX:0063006c EDX:3bad4fe3 ESI:779bfb48 EDI:77c453e0 Stack dump: 0x7292809c: 0020 779bfc58 0019 77c453e0 0x729280ac: 729280c8 779a7349 77c453e0 ff9cff99 0x729280bc: 77978600 8000 779a71d4 729280f0 0x729280cc: 7795c80b 8000 03bd 77c453e0 0x729280dc: 77c45500 72ad5e00 03bd 0x729280ec: 72ad8b40 72928120 72ab84d8 779a71d4 Backtrace: =>1 0x779a6b3b DSOUND_WaveQueue+0x9b(device=0x77c453e0, mixq=0xff9cff99) [/home/julliard/wine/wine/dlls/dsound/mixer.c:931] in dsound (0x729280ac) 2 0x779a7349 DSOUND_callback+0x175(hwo=0x8000, msg=0x3bd, dwUser=0x77c453e0, dw1=0x77c45500, dw2=0x0) [/home/julliard/wine/wine/dlls/dsound/mixer.c:1168] in dsound (0x729280c8) 3 0x7795c80b DriverCallback+0x1a3(dwCallBack=0x779a71d4, uFlags=0x3, hDev=0x8000, wMsg=0x3bd, dwUser=0x77c453e0, dwParam1=0x77c45500, dwParam2=0x0) [/home/julliard/wine/wine/dlls/winmm/driver.c:521] in winmm (0x729280f0) 4 0x72ab84d8 wodNotifyClient(wwo=0x72ad8b40, wMsg=0x3bd, dwParam1=0x77c45500, dwParam2=0x0) [/home/julliard/wine/wine/dlls/winmm/wineoss/audio.c:1330] in wineoss.drv (0x72928120) 5 0x72ab8a16 wodPlayer_NotifyCompletions+0xea(wwo=0x72ad8b40, force=0x1) [/home/julliard/wine/wine/dlls/winmm/wineoss/audio.c:1561] in wineoss.drv (0x72928144) 6 0x72ab8aa2 wodPlayer_Reset(wwo=0x72ad8b40, reset=0x1) [/home/julliard/wine/wine/dlls/winmm/wineoss/audio.c:1610] in wineoss.drv (0x7292817c) 7 0x72ab8d3e wodPlayer_ProcessMessages(wwo=0x72ad8b40) [/home/julliard/wine/wine/dlls/winmm/wineoss/audio.c:1701] in wineoss.drv (0x729281b0) 8 0x72ab8fe5 wodPlayer(pmt=0x0) [/home/julliard/wine/wine/dlls/winmm/wineoss/audio.c:1795] in wineoss.drv (0x729281dc) 9 0x77bd8867 THREAD_Start(ptr=0x77c45500) [/home/julliard/wine/wine/dlls/kernel/thread.c:107] in kernel32 (0x729282a8) 10 0x77ee09aa start_thread+0x142(info=0x77c45520) [/home/julliard/wine/wine/dlls/ntdll/thread.c:204] in ntdll (0x72928ad8) 11 0xb7fb1b63 start_thread+0x93 in libpthread.so.0 (0x72928b4c) 12 0xb7f5018a __clone+0x5a in libc.so.6 (0x) 0x779a6b3b DSOUND_WaveQueue+0x9b [/home/julliard/wine/wine/dlls/dsound/mixer.c:931] in dsound: pushl 0x29c(%eax,%edi,1) 931 waveOutWrite(device->hwo, device->pwave[device->pwwrite], sizeof(WAVEHDR)); -- Alexandre Julliard [EMAIL PROTECTED]
Re: wine/dlls/x11drv keyboard.c
On Sun, 29 May 2005, Alexandre Julliard wrote: [...] Log message: Dmitry Timoshkov <[EMAIL PROTECTED]> Fix Estonian keyboard layout to better match the X11 one. I have noticed that we get a steady trickle of these. Shouldn't it be possible to get the definitions of all keyboards from the XFree sources and find some way to automatically import them? The other trickle we're seeing is with timezones. So in a similar way maybe we could get the data from the site below and import it all: http://www.timeanddate.com/library/abbreviations/timezones/ Would this make sense? -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.
Re: Half Life 2 error -- err:mmio:MMIO_ParseExtA
Am Sonntag, 29. Mai 2005 20:10 schrieb J. Grant: > Hello, > > I am getting this error when trying to run Half Life2 in > err:mmio:MMIO_ParseExtA. Could someone tell me if this is a problem in > in WINE, or a problem in my setup? Or not an error at all..? > > Also if there is already a document on setting up Half Life2 could > someone direct me to it please, I could not find one already. These look harmless to me, the problem you have is that Steam refuses to work with Wines builtin shdocvw.dll and mshtml.dll, no matter if you install the Mozilla ActiveX control. Try installing Internet Explorer and set shdocvw and mshtml to native and try again. Stefan
CRYPTPROTECT_LOCAL_MACHINE in CryptProtectData
Hi Kees, rsaenh uses your Crypt[Un]ProtectData functions for protecting the user's private keys, which are stored in the registry. For machine key pairs (which are keys that belong to the machine instead of a certain user), rsaenh needs support for the CRYPTPROTECT_LOCAL_MACHINE flag. On possible implementation would be to derive the key from the computer name (GetComputerName) instead of from the user's login name, if the flag is set. Would you mind implementing something like this? Bye, -- Michael Jung [EMAIL PROTECTED]
Re: Flush serial port
> "Alexandre" == Alexandre Julliard <[EMAIL PROTECTED]> writes: Alexandre> Uwe Bonnes <[EMAIL PROTECTED]> writes: >> Changelog: wine/server/file.c: create_file() If we open a serial >> device, flush it Alexandre> This should be done in serial.c, but could you please explain Alexandre> why this is necessary? The flush is not necessary! Probably some error in my test program made me think it was nesessary. -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Optionally map the unix filesystem instead of drive letters into the shell namespace
On Monday 30 May 2005 02:12, you wrote: > Please explain on the per process basis. If you mean let winelib > application change the global flags via wine API, there will be > synchronization and threading issues. Say application A turn on unix path, > application B turn on unix path, application B exit and turn off unix path, > then application A will now be back in dos path. > Or do you mean each application would have their own registry setting > and this per application setting is set when application is installed? Then > there is problem of how wine get to this application specific settings. The ShowUnixFilesystem option in the registry could be global or application specific. In the current patch it's global. But it could be something like [AppDefaults\\winword.exe\\shell32] "ShowUnixFilesystem" = "1" which would turn it on only for winword (This syntax is common in wine's config file). Back to the winelib case. Suppose the user did choose not to display the unix filesystem at all. We could implement an API, say show_unix_filesystem(BOOL on), which would turn the feature on for the current process, no matter what the user chose in the registry. (By setting the option_show_unix_filesystem variable, which currently is in scope only in the show_unix_filesystem function, but valid process-wide). > What I mean here is when user is browsing unix path and be able to type > in dos path seems a bit strange. Just the little things that doesn't make it > feel really in unix mode for winlib app. You mean like the user types in "Z:\home\mjung\" and thinks: "Gosh, this should work only for unix paths. What did those crazy wine hackers think?". In my opinion, this is really a no-problem. The user should be able to enter unix paths, that's for sure (it doesn't work currently, though, but should be relatively easy to fix). But the possibility that the user enters a dos path by accident and then wonders why this works is pretty low, I think. > Sorry if I offended you, that wasn't my intention. Initially it was just > a direct email sent to Alexandre to ask the status of the patch I previously > sent. If it has been rejected, I would like to know the reason so I can make > changes and send in another patch. Should have cc wine-devel, my apologies. Never mind. In your last mail you said that you already implemented "rename" and "new folder" functionality. Are those restricted to shfldr_unixfs? Do you think those could be sent as a separate patch already? That would be sweet. Bye, -- Michael Jung [EMAIL PROTECTED]
Re: tab: Shift selected tab text up instead of down
On 5/29/05, Vitaliy Margolen <[EMAIL PROTECTED]> wrote: > Sunday, May 29, 2005, 2:17:12, Vitaliy Margolen wrote: > > Hi, > > > Changelog > > * Shift selected tab text up instead of down. > >- drawRect->>bottom += 3; > >+ drawRect->>bottom -= 3; > > This does not shift tab up. The location of the tab stays the same. The text is shifted up. > This will shrink tab text area instead of growing it Using gimp I've measured the size of the 's' of a selected tab and the 's' of a non-selected tab with my change and with native comctl32, and the height of the s' is always 6 pixels in all four cases. > Also you missed note above about keeping TAB_DrawItem in sync with this part. I couldn't find the code in question in TAB_DrawItem. > All these numbers had been verified against native, including custom drawn > tabs I don't refute the validity of the numbers, I'm sure they're right. The problem is that the text of selected tabs in wine cvs are drawn below the text of unselected tabs, which is not correct. I've attached three screenshots of winecfg's first few tabs. They are of wine cvs, wine with my patch applied, and the last is with native comctl32. -- James Hawkins <><><>
