- Wine-Devel - list.winehq.org

CryptoAPI
by unknown＠example.com April 5, 2004

April 5, 2004

Has anybody started implementing CryptoApi in WINE?? If no mayby someone can give me some clues how to start... I am not bad i C++ I think, but I have never make thing like that. I don't promise I will do that, but I can try... :)

3 2

Re: CryptoAPI
by Juan Lang April 5, 2004

April 5, 2004

Jacek wrote: > Has anybody started implementing CryptoApi in WINE?? > If no mayby someone can give me some clues how to > start... I am not bad i C++ I think, but I > have never make thing like that. I don't promise I > will do that, but I can try... :) Hi Jacek, take a look at Wine's rsabase.dll, that DLL doesn't do very much yet. All its functions (CPAcquireContext, etc) are described here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/s… If you have access to a Windows box it's easier: you can load the DLL itself and call all the functions and try to reproduce what it's doing. Good luck, --Juan __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

1 0

Re: Fwd: Re: appdb - improvement in serching out bugs
by tony_lambregts＠telusplanet.net April 5, 2004

April 5, 2004

Quoting hatky <hatky(a)hatky.myz.info>: >> No, no, no... read the patch again. > Ok, sorry wasn't what I tought you are trying to do, this patch is ok > p.s. I didn't think someone actually changed the urls in bugzilla. sweet :). I have been going through them 100 at a time. I've got 1-400 done at this time. I figure I will be done sometime before Christmas :P. If anyone wants to help with this I would be glad to have the help... Check out http://bugs.winehq.org/show_bug.cgi?id=560 for more more on this. -- Tony Lambregts

1 0

NtPulseEvent
by Robert Lunnon April 5, 2004

April 5, 2004

What is the status of NtPulseEvent it emits a diagnostic messages fixme:ntdll:NtPulseEvent (7c,0) yet it looks to me that NtPulseEvent is implemented but the fixme is bogus Anyone know about this ? BTW Has anyone experience with the Skype application under linux, does it work there ? Bob b

2 1

Should winemaker be able to handle this
by Bill Medland April 5, 2004

April 5, 2004

I haven't been following the winemaker stuff so I don't know whether it is supposed to be able to handle this (and is broken) or not. I am having to play with the "build a builtin dll to wrap a linux so" concept again after a year or so since the last time, as discussed in the Winlib manual, chapter 5. I see that winemaker has changed since then. In particular the bit that is not working for my case is the -D, -I, -L and -l options. What I want is to run winemaker to generate the build environment and then do the build. What I used toi have was: #! /bin/bash # Run this script in order to pass the correct arguments to winemaker so that # it can set up the build environment winemaker --nosource-fix --nogenerated-specs --dll --single-target mytarget --nomfc -DMY_SETTING -I$MY_INC_DIR -L$MY_LIB_DIR -lmylinuxso . I see that we don't bother with generating spec files any longer. However I see that the -D, -I, -L and -l options don't find their way into the Makefile these days. Is that by design or a bug? (i.e. do I have to fix winemaker or do I need to look at a different way of doing it) -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

4 5

RE: Handling dialogs created without using templates
by Santosh Siddheshwar April 5, 2004

April 5, 2004

Hi, Thanks. Would you be able to share details of the changes you did for handling MDI windows? Regards Santosh > -----Original Message----- > From: Dmitry Timoshkov [SMTP:dmitry(a)baikal.ru] > Sent: Tuesday, March 30, 2004 7:40 PM > To: Santosh Siddheshwar > Cc: wine-devel(a)winehq.com > Subject: Re: Handling dialogs created without using templates > > "Santosh Siddheshwar" <santosh.s(a)sonata-software.com> wrote: > > > Yes attached is a sample which is pretty similar to what I described > > below. > > Thanks. Now I see where the problem is. We have to hook dialog creation > code into common window creation code, something similar to what I've done > recently for MDI. Alexandre, are my thoughts correct? > > -- > Dmitry. ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

2 1

Re: Re: dbghelp
by Pouech Eric DMI AEI CAEN April 5, 2004

April 5, 2004

> UnDecorateName is still a stub, while our winedump has some a good > framework for UnDecorateName, also translating into a GCC way and not in a > VC++ way. How should these things go together? See the comment in dbghelp.c !! My first thouhgt would be to make a .a lib out of winedump code, and use it in winedump and msvcrt and / or dbghelp. I haven't studied yet the best way to share the code between msvcrt and dbghelp A+

1 0

Re: appdb - improvement in serching out bugs
by tony_lambregts＠telusplanet.net April 5, 2004

April 5, 2004

Quoting hatky <hatky(a)hatky.myz.info>: > > On Sunday 04 April 2004 06:21, tony_lambregts(a)telusplanet.net wrote: > > The current code can get bugs that have nothing to do with the AppDB. > This > > should fix it. > > > > -- > > > > Tony Lambregts > > I think this is wrong, you are saying the url in bugzilla should be exactly > "appdb #" where it should realy be > "http://bugs.winehq,org/show_bug.cgi?id=#" > > No, no, no... read the patch again. The current code is correct as far as it goes, but it grabs the substring. So when the appdb# is 68 it grabs bugs that for appid 680, 681... 689. It will also grab bugs that just happen to have 68 in the url. My testing with this has been limited somewhat since I have not been able to set up the appdb on my machine but I know enough to know that the code as I have submitted will do what it needs to do. -- Tony Lambregts

2 1

Re: appdb - improvement in serching out bugs
by tony_lambregts＠telusplanet.net April 4, 2004

April 4, 2004

Quoting hatky <hatky(a)hatky.myz.info>: > > On Sunday 04 April 2004 06:21, tony_lambregts(a)telusplanet.net wrote: > > The current code can get bugs that have nothing to do with the AppDB. > This > > should fix it. > > > > -- > > > > Tony Lambregts > > I think this is wrong, you are saying the url in bugzilla should be exactly > "appdb #" where it should realy be > "http://bugs.winehq,org/show_bug.cgi?id=#" > > No, no, no... read the patch again. The current code is correct as far as it goes, but it grabs the substring. So when the appdb# is 68 it grabs bugs that for appid 680, 681... 689. It will also grab bugs that just happen to have 68 in the url. My testing with this has been limited somewhat since I have not been able to set up the appdb on my machine but I know enough to know that the code as I have submitted will do what it needs to do. -- Tony Lambregts

1 0

Re: dbghelp
by Uwe Bonnes April 4, 2004

April 4, 2004

>>>>> "Eric" == Eric Pouech <pouech-eric(a)wanadoo.fr> writes: Eric> Eric Pouech a écrit : >> This is a first (and incomplete) shot at implementing the dbghelp >> DLL. Eric> forgot to say that: - this patch must be applied before the ones Eric> on imagehlp & taskmgr - code is highly derivated from winedbg Eric> current code Eric> I'm also working on a winedbg version based on this DLL, but it Eric> isn't ready yet (as dbghelp seems to get a bit more mature, I Eric> thought some people might be interested in testing it) UnDecorateName is still a stub, while our winedump has some a good framework for UnDecorateName, also translating into a GCC way and not in a VC++ way. How should these things go together? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0