Re: black-box implementation of CryptProtectData/CryptUnprotectData

2005-04-04 Thread Mike McCormack
Kees Cook wrote: This patch implements a functional replacement for crypt32.dll's CryptProtectData and CryptUnprotectData. It does _not_ perform any encrypt/decryption, but rather tracks the cipher/entropy/plain triplets so that programs depending on the calls will operate correctly. Perhaps

Re: Wine device drivers proposal

2005-04-04 Thread Andreas Mohr
Hi, On Mon, Apr 04, 2005 at 08:58:32AM +1000, Troy Rollo wrote: Of course such a mechanism would be much slower than a native driver, and may run into problems with timing issues. Interrupts pose a particular challenge in that ideally the process handling the device should be activated

Re: Wine device drivers proposal

2005-04-04 Thread Andreas Mohr
Hi, On Sun, Apr 03, 2005 at 08:20:48PM -0400, C. Scott Ananian wrote: On Mon, 4 Apr 2005, Troy Rollo wrote: run into problems with timing issues. Interrupts pose a particular challenge in that ideally the process handling the device should be activated immediately, and the Linux kernel

Re: black-box implementation of CryptProtectData/CryptUnprotectData

2005-04-04 Thread Michael Jung
On Monday 04 April 2005 08:01, Mike McCormack wrote: Kees Cook wrote: This patch implements a functional replacement for crypt32.dll's CryptProtectData and CryptUnprotectData. It does _not_ perform any encrypt/decryption, but rather tracks the cipher/entropy/plain triplets so that

Re: Wine device drivers proposal

2005-04-04 Thread Damjan Jovanovic
--- James Courtier-Dutton [EMAIL PROTECTED] wrote: Damjan Jovanovic wrote: Hi I've been trying to add STI (still image) support to Wine, and I've made some progress. However, I see a deep and unsurmountable need to add (at least user-space) device drivers to Wine, and I would

Re: Wine device drivers proposal

2005-04-04 Thread Damjan Jovanovic
--- Kuba Ober [EMAIL PROTECTED] wrote: I've been trying to add STI (still image) support to Wine, and I've made some progress. However, I see a deep and unsurmountable need to add (at least user-space) device drivers to Wine, and I would like some feedback on these ideas.

Re: [SERVER] fix potential leak on window.c (bug2849)

2005-04-04 Thread Dimitrie O. Paun
On Mon, Apr 04, 2005 at 09:38:40AM +0200, Raphael wrote: Hi, changelog: - fix potential leak on window.c as seen in bug2849 + { + free_region( tmp ); + goto error; + } Can you please use 4-spaces indentation, like the rest of

Re: WineConf Agenda

2005-04-04 Thread Dimitrie O. Paun
On Mon, Apr 04, 2005 at 04:19:36PM +1000, Andrew Tridgell wrote: Personally I think that keeping a full alternative dcache in userspace isn't the right approach. I think we could bear the hit of something that keeps O(number_of_directories) memory, but not O(number_of_files). The lack of a

Re: WineConf Agenda

2005-04-04 Thread Andrew Tridgell
I should also say that if the WineConf agenda doesn't have enough room for us to complete our Wine-Samba discussions, then I'd like to invite any Wine developers who would like to continue the discussion to come to the SambaXP conference which takes place directly after WineConf just a few hours

Re: WineConf Agenda

2005-04-04 Thread Andrew Tridgell
Dimitrie, Speaking of which, both Samba and Wine suffer from the lack of support of cases-insensitivness in the kernel. Now, I'm not suggesting that we should push for that (I'm aware of the past discussions on LKML, and I must agree with Linus), but we should push for *something* that's

Re: WineConf Agenda

2005-04-04 Thread Andrew Tridgell
Steven, Finally, if we have time, I'd like to discuss cooperation on IDL files and MSRPC interfaces. Yes I would like to discuss this as well. Eirc Kohl has made quite a lot of changes to WIDL for ReactOS to support our MSRPC and PLug and Pray implementation and I would like to see

Re: WineConf Agenda

2005-04-04 Thread Andrew Tridgell
Dimi, - for mixed directories, Win32 names will appear lowercase to posix programs, but will be case preserving to Wine/Samba. Wine/Samba This is something I don't really like: to change the filename's case behind user's back. From my POV, it's not acceptable. I know I'd be

Re: black-box implementation of CryptProtectData/CryptUnprotectData

2005-04-04 Thread Kees Cook
On Sun, Apr 03, 2005 at 11:04:53PM -0500, James Hawkins wrote: On Apr 3, 2005 10:12 PM, Kees Cook [EMAIL PROTECTED] wrote: To store the triplets, these functions use the registry: Registry Layout: HKEY_CURRENT_USER\Software\Wine\Crypt\ProtectData\Map\[index] Cipher:

Re: black-box implementation of CryptProtectData/CryptUnprotectData

2005-04-04 Thread Kees Cook
On Sun, Apr 03, 2005 at 11:56:34PM -0500, James Hawkins wrote: we do it should be encapsulated. What I'm getting at is that just because this implementation is wine-specific doesn't mean some of the implementation data should go in Software\Wine. Software\Wine is where the configurations of

Re: WineConf Agenda

2005-04-04 Thread Jakob Eriksson
Dimitrie O. Paun wrote: On Sun, Apr 03, 2005 at 08:57:58PM +1000, Andrew Tridgell wrote: In each case I will be trying to encourage methods which can store the full NTFS semantics, rather than limiting ourselves to only the things that fit natually in posix filesystems. I'm guessing we will

Re: WineConf Agenda

2005-04-04 Thread Andrew Tridgell
Dimi, I understand that, but I'd certainly fall into the minority of Samba users then. I share my /home/dimi directory via Samba to my laptop, there's no way I want my filenames modified by the system. Existing filenames, and names that are crated by posix don't get modified of course. By

Re: registry: order of insertion of values

2005-04-04 Thread Paul Millar
Hi James, On Sunday 03 Apr 2005 23:57, you wrote: On Apr 3, 2005 5:17 PM, Paul Millar [EMAIL PROTECTED] wrote: By the look of it, the bug is that create_test_entries() creates the three TestN keys (N=1..3), but doesn't clean them after. We use the values created in create_test_entries()

Re: WineConf Agenda

2005-04-04 Thread Mike Hearn
On Mon, 2005-04-04 at 16:19 +1000, Andrew Tridgell wrote: Unfortunately it doesn't really help with case-insensitivity, as it is a non-blocking async interface, so the listeners get told way too late. Plus you have to have every directory open that you want to monitor, which would get silly.

Re: black-box implementation of CryptProtectData/CryptUnprotectData

2005-04-04 Thread Kees Cook
On Mon, Apr 04, 2005 at 03:01:53PM +0900, Mike McCormack wrote: Perhaps you could make it work right by using a key stored in ssh-agent? Well, by working right, it means that taking a cipher/entropy from Windows and calling CryptUnprotectData on it in Wine would return the plain text. This

Re: black-box implementation of CryptProtectData/CryptUnprotectData

2005-04-04 Thread Mike McCormack
Kees Cook wrote: Actually, I did that to avoid the line prefix that TRACE adds. All the stuff where I call the dbg functions directly are part of helper functions, and seeing their names is confusing while watching a Protect/Unprotect session. It's probably better to keep it consistent with

Re: black-box implementation of CryptProtectData/CryptUnprotectData

2005-04-04 Thread Mike McCormack
Kees Cook wrote: It's probably better to keep it consistent with what the rest of Wine does. I'd really like to push back on this. The traces become unreadable as the various function names change. I think the debugging as I have it is more useful than how it looks with only TRACE calls. The

Re: Hints needed for riched20/scroll bug solving

2005-04-04 Thread Paul Vriens
On Sun, 2005-04-03 at 09:09, Krzysztof Foltman wrote: Paul Vriens wrote: agreement appears. I know that nobody reads this ;-) but hey. When I click in the scrollbar (page down) the page goes down 1 page and the scrollbar changes. My newest patch (released 5 minutes ago, not in CVS

Re: [riched20/list.c] Exception in ME_DumpDocument

2005-04-04 Thread Paul Vriens
On Tue, 2005-03-15 at 20:44, Robert Shearman wrote: Paul Vriens wrote: Hi, After I found that one of the files still contained a debugchannel for riched20 (instead of richedit), I added both to see a trace (just for the fun of it). This however raised an exception in ME_DumpDocument:

Re: black-box implementation of CryptProtectData/CryptUnprotectData

2005-04-04 Thread Kees Cook
On Tue, Apr 05, 2005 at 01:07:14AM +0900, Mike McCormack wrote: It's probably better to keep it consistent with what the rest of Wine does. I'd really like to push back on this. The traces become unreadable as the various function names change. I think the debugging as I have it is more

Re: registry: order of insertion of values

2005-04-04 Thread James Hawkins
On Apr 4, 2005 4:26 AM, Paul Millar [EMAIL PROTECTED] wrote: Hi James, On Sunday 03 Apr 2005 23:57, you wrote: On Apr 3, 2005 5:17 PM, Paul Millar [EMAIL PROTECTED] wrote: By the look of it, the bug is that create_test_entries() creates the three TestN keys (N=1..3), but doesn't clean

Re: [wine] Re: KERNEL: Implement undocumented SetCPGlobal API call

2005-04-04 Thread David Lee Lambert
On Thu, Mar 31, 2005 at 03:18:27PM +1100, Troy Rollo wrote: That assumes every process is OK working with the same code page. This is not necessarily the case with a server application, which may well be serving clients in multiple regions in a multi-national environment. I know one major

Should all A functions forward to their respective W's?

2005-04-04 Thread James Hawkins
Hi, In the current state of wine, we have several A/W functions. Sometimes both the A and W functions are separately implemented with an ansi and unicode implementation respectively. Other A/W functions have the A forward to the W, converting the ansi to unicode. For all the functions that

Re: Fix GDI_PAL_COLORS crash.

2005-04-04 Thread Dmitry Timoshkov
Glenn Wurster [EMAIL PROTECTED] wrote: GDI_PAL_COLORS is composed of 16 bit indexes, we only got the first 256 colours. Instead of making a copy of possibly 65535 different palette entries in the logical palette, get a pointer and build up the dib colours as needed. Yes, the % is how

real SetProcessClass and SetThreadPriority support

2005-04-04 Thread Robert Reif
Are there any plans or is anyone working on mapping Windows SetProcessClass and SetThreadPriority support to linux process priorities on kernels that support CAP_SYS_NICE?

Re: Wine device drivers proposal

2005-04-04 Thread Troy Rollo
On Mon, 4 Apr 2005 10:20, C. Scott Ananian wrote: Um, I'm fairly certain that rendezvous via any kernel synchronization mechanism (semaphores, condition variables, etc) will do exactly what you want. The blocked task goes to sleep and the rest of the time slice is preferentially transfered

Re: [wine] Re: KERNEL: Implement undocumented SetCPGlobal API call

2005-04-04 Thread Troy Rollo
On Tue, 5 Apr 2005 05:30, David Lee Lambert wrote: The solution in this case is to use Unicode internally, and then add calls to WideCharToMultibyte()... This situation is an even worse case to try hacking the undocumented Windows internationalization APIs. Remember, for instance, that

Re: crypt32: CryptProtectData/CryptUnprotectData take 2

2005-04-04 Thread Mike McCormack
Kees Cook wrote: ChangeLog: Black-box implementation of CryptProtectData/CryptUnprotectData. Here is an updated patch with various recommendations implemented. Hi Kees, The new patch looks good. I should have mentioned before that writing a test case will help your patch be accepted. Did