August 2003 - Wine-devel - list.winehq.org

problems with spec/def and import libs on Mingw
by Steven Edwards 27 Aug '03

27 Aug '03

Hello, Recent changes with the self regsitering of dlls are causing dependency problems on Mingw. If I compile shell32 on windows it is link to a function in ole32.dll named "PRIVATE". If course in the spec.def file we have the following information: DllGetClassObject(a)12=OLE32_DllGetClassObject(a)12 @63 PRIVATE DllRegisterServer(a)0=OLE32_DllRegisterServer(a)0 @194 PRIVATE DllUnregisterServer(a)0=OLE32_DllUnregisterServer(a)0 @266 PRIVATE Is there a simple fix for the Mingw case? Thanks Steven __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

1 0

Re: PATCH - winnt.h move non-standard language IDs to wine/port.h
by Dimitrie O. Paun 26 Aug '03

26 Aug '03

On August 21, 2003 08:23 pm, Steven Edwards wrote: > It took a little bit of work but I managed to get a *.dsw for wrc to work. > > Changelog: WRC Porting fix. Move non-standard Language IDs Alexandre, We still have a few (hard to remove) "#ifdef __WINESRC__" in our headers. We all agree they should be removed, but they are not trivially removable right now. I say we should move all such extensions to a "wine/internal.h" header. This will accomplish a few things: -- make the task of compiling with other headers a lot easier. This will further result in more portability and header fixes for our standard headers, which is a Good Thing(TM). -- the "wine/internal.h" include should be included only from .c files, thus explicitly marking such offenders, and providing a list of things that need to be addressed. -- the "wine/internal.h" header itself will serve as a quick "TODO" for people interested in fixing these. The last two points will also make it easier to see where we're using undesirable extensions. Whatdayasay? -- Dimi.

5 11

Question about winedump and winemaker
by dd jj 26 Aug '03

26 Aug '03

Hello everyone, I am using Redhat 9 and wine-20030813. I used winemaker and winedump to generate a dll.so file, but there are some problems here: 1)winemaker doesn't work at all, I just followed all the instructions, have no idea what's going on...(Does anyone did this before?) 2)winedump works, but I need to change something in the .spec.c file, there is a sentence like: asm(..... ...... "\t.string \"_test1\"\n") ..... ) Later when I run my program, it will complain that : err:module:import_dll No implementation for test.dll._test1(a)4 imported from ... So I thought maybe I need add @4 to "\t.string\"test1\"\n" , make it come into: "t.string \"_test1(a)4\"\n"; Then it works! But now I need to implement 2 or over 2 functions in the dll.so, after the modification, only one function works regardless the sequence of these functions in my source codes.. Does anyone have such experience before, thank you for help this out. Is there any bug for winedump or winemaker ? Thanks --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software

1 0

Deleted emails
by Duane Clark 26 Aug '03

26 Aug '03

Ahh..., fun with the Sobig.F virus. I skipped out yesterday to do some scuba diving, and arrived this morning to find about 7000 emails awaiting moderation. Yikes!!! Anyway, Jeremy seems to have fixed things so they are now being blocked. Thanks!!! But rather than trying to go through 7000 postings to find legitimate emails, all pending moderation requests were simply deleted. So if anyone posted something to any of the lists in about the 36 hours or so prior to this morning, and it never showed up, please just resend.

1 0

Re: Thank you!
by Alexandre Julliard 26 Aug '03

26 Aug '03

Please see the attached file for details.

3 2

Re: cab_G_00-r2
by Gregory M. Turner 26 Aug '03

26 Aug '03

On Tuesday 26 August 2003 12:49 pm, Gregory M. Turner wrote: > This simply reconciles cab_G_00 with CVS. > > License: Bugroff > > * dlls/setupapi: Makefile.in, setupapi_private.h, > setupx_main.c, stubs.c, setupapi.h, setupcab.c (new) > Greg Turner <gmturner007(a)ameritech.net> > - implement (most of) SetupIterateCabinet. oops, this doesn't seem to compile... looking into it. until I figure out what's wrong, please don't apply. -- gmt "We have to get basically voters to say 'I'd like to vote for the politician who thinks of global equity'" -- Bill Gates, World Economic Forum 2002

1 0

Fwd: Printing in Wine + FreeBSD
by Jonathan Fosburgh 26 Aug '03

26 Aug '03

---------- Forwarded Message ---------- Subject: Printing in Wine + FreeBSD Date: Tuesday 26 August 2003 07:18 am From: Jonathan Fosburgh <syjef(a)mdanderson.org> To: wine-users(a)winehq.com This behaviour has been consistent on FreeBSD -Current since 5.0-RELEASE. I am now running 5.1-CURRENT with cups-1.1.19.0 and wine from CVS yesterday afternoon. Wine *is* seeing my cups printers and I can print to them from the command line, from kprinter, etc. However, when trying to print from, say, notepad, I receive the following errors for any of my printers: fixme:commdlg:PRINTDLG_SetUpPrinterListComboW Can't find '(null)' in printer list so trying to find default err:commdlg:PRINTDLG_ChangePrinterW DocumentProperties fails on L"aix-ptr" fixme:commdlg:PRINTDLG_UpdatePrintDlgW No lpdm ptr? fixme:commdlg:PRINTDLG_WMCommandW Update printdlg was not successful! The only other application I have installed from which I would like to print is Lotus Notes R5. A coworker using Red Hat has no problem printing from Notes, but I receive an insufficient memory error. Does anyone have printing from wine working on FreeBSD? Do these errors make sense to anyone reading this list? I have searched for them and came across some entries, but they were all fairly old, and I couldn't find one that applied. Thanks for any help you can offer. -- Jonathan Fosburgh AIX and Storage Administrator UT MD Anderson Cancer Center Houston, TX _______________________________________________ wine-users mailing list wine-users(a)winehq.com http://www.winehq.com/mailman/listinfo/wine-users ------------------------------------------------------- I originally posted this to wine-users and it was suggested I try here ... -- Jonathan Fosburgh AIX and Storage Administrator UT MD Anderson Cancer Center Houston, TX

1 0

Re: [winecfg 1] Implement saveConfigValue(), style changes, code cleanup, UI alignment
by Dimitrie O. Paun 26 Aug '03

26 Aug '03

On 26 Aug 2003, Mike Hearn wrote: > ChangeLog: > - Correct return code of loadConfig() > - Make the registry key used a constant > - Change registry key used to WineHQ\Wine > - Made code slightly more consistant with itself > - Some style changes, expanding out variable names, whitespace, removing > unnecessary variable initializers and hungarian notation etc > - Replace dialog box with a FIXME in WinMain() to warn of incompleteness > - Implement saveConfigValue() > - Hook up support for save/load of WinVer Dude, and the patch?!? -- Dimi.

1 0

CVS Stalls
by jeff_latimer 26 Aug '03

26 Aug '03

People, I have just started having problems with CVS update -PAd where it has started to stop at: cvs server: Updating wine/tools/wpp cvs server: Updating wine/tools/wrc cvs server: Updating wine/tsx11 cvs server: Updating wine/unicode cvs server: Updating wine/win32 cvs server: Updating wine/windows cvs server: Updating wine/windows/ttydrv cvs server: Updating wine/windows/x11drv This is consistent though it has been working well for me for some time before that. Is there a solution? Jeff ---------------- Powered by telstra.com

2 1

Re: remove some __WINESRC__es
by Alexandre Julliard 26 Aug '03

26 Aug '03

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > No need to clutter the header files with these tests. > We have enough of a review process in place to avoid > such things, and in any way, things like > > #ifdef __WINESRC__ > # undef UNICODE > #endif /* __WINESRC__ */ > > simply encourage bad coding, hides problems, and it's > confusing. I agree for UNICODE, but not for NEAR, FAR etc. Allowing them in Wine will actually encourage bad coding, since we will see FAR pointers pop up all over the place. A better approach would be to #define them to something like do_not_use_this when building Wine. -- Alexandre Julliard julliard(a)winehq.com

2 1