- Wine-Devel - list.winehq.org

Re: PATCH: Re: Wine does not build (preloader.c, line 863, a_ptr union)
by Mike Hearn June 2, 2005

June 2, 2005

On Thu, 02 Jun 2005 09:58:39 +0200, Andreas Mohr wrote: > But OTOH projects have to do binary incompatible changes a bit before > the release of the next major version, otherwise there won't be any testing. > And perhaps glibc is in such a version change phase right now... No, it's just a totally screwed project from the perspective of versioning. You know they're making it harder and harder to access LinuxThreads, and it's scheduled for deletion from Fedora Core entirely? thanks -mike

1 0

Re: [include/winternl.h #6] SYSTEM_PROCESS_INFORMATION
by Robert Shearman June 2, 2005

June 2, 2005

Paul Vriens wrote: >Hi, > > Hi Paul, >the first bigger change to SYSTEM_PROCESS_INFORMATION. The structure now >contains VM_COUNTERS (which had to move up in the file) instead of all >the single (wrong) items, and IO_COUNTERS. I also added 2 extra FILETIME >items (well actually I changed dwUnknown2[5]). > >This structure now has the correct size for W2K/WinXP and W2K3. NT >doesn't have the IO_COUNTERS part, but for now I'm not to worried about >dealing with that (unless somebody tells me to). > >I also had to change ntdll/nt.c because of this. I removed all the >single sets to 0 as this is done by the memset anyway. > >Next patches will change the struct (and related files) to use >UNICODE_STRING for the process name, but I'm having a few issues with >that. > >Next patches will also contain tests to prove the above. Can anybody >(who's not tired of reading until now) tell me if we really need the >__WINESRC__ in that structure, the Windows structure shown is wrong >anyway > We shouldn't need the __WINESRC__ ifdef. No code that is designed to be portable to Microsoft's headers should be using winternl.h. >and how can I check 'my' struct in a test (for now I've copied it >to the test and renamed it to something non-existent)? > > I think that is the only way to do it. -- Rob Shearman

1 0

Re: [moniker 2] Fix FileMoniker::Load/Save
by Robert Shearman June 2, 2005

June 2, 2005

On Thursday 02 June 2005 09:47, Richard Cohen wrote: > Changelog > - Base FileMonikerImpl_Save() on XP > - Correct handling of Unicode strings & multibyte locales > - More error checking > - Change ERR to WARN > - Match Windows quick & dirty estimate for GetSizeMax() Hi Richard, Well done for fixing the Load & Save functions. However, there is one problem that isn't still fixed - paths that exist are saved with the Unicode version of their path name, but paths that don't are saved without. I'll make a patch to fix this if you think it's outside the scope of your current moniker fixes. Thanks, Rob

2 1

Re: fixes for -Wmissing-declarations and -Wwrite-strings warnings
by Pouech Eric DMI AEI CAEN June 2, 2005

June 2, 2005

returning a pointer to something on the stack is something I call an error (how do you ensure that the buffer will not get overwritten by another function call ?) A+ > Message du 02/06/05 15:25 > De : "Dimi Paun" > A : pouech-eric(a)wanadoo.fr, wine-devel(a)winehq.org > Copie à : > Objet : Re: fixes for -Wmissing-declarations and -Wwrite-strings warnings > > From: "Pouech Eric DMI AEI CAEN" > > looking at the patch, I saw something in the code that made me sick: > > char *audioAutoDetect(void) > > { > > [snip] > > char *driversFound[10]; > > [snip] > > return driversFound[0]; > > [snip] > > } > > > > can someone fix that broken code ? > > Yeah, it's not pretty, but just by looking at this snippet there is no > obvious error in the above AFAICT.

3 2

Re: [moniker 2] Fix FileMoniker::Load/Save
by Mike McCormack June 2, 2005

June 2, 2005

Nice patch, and nice test case. > - DWORD constant1 = 0xDEADFFFF; /* these constants are detected after analysing the data structure written by */ > - WORD constant2 = 0x3; /* FileMoniker_Save function in a windows program system */ > + DWORD DEADFFFF = 0xDEADFFFF; /* Constants */ > + DWORD ZERO = 0; > + WORD THREE = 0x3; In C, variables are traditionally lower case, and macros are upper case. Mike

1 0

Feasible google summer of code project?
by Joseph Garvin June 2, 2005

June 2, 2005

I asked in #winehq where I should ask about this, and I was sent here. So no flames if they were horribly wrong, I tried ;) I'm an undergraduate CS student, and I've been reading the wine newsletter for a while now because I find the project rather cool to watch. When I started using Linux a year ago wine didn't run my screenwriting software at all -- it's now fully functional. That's just flippin' sweet :) So, naturally, I'm excited at the idea of maybe hacking on wine. I'm not a super experienced C programmer. I know Standard C but have never actually worked on a large project in it before. I pick up new languages rather quickly though, and I've worked in Java, C, C++, Matlab, Lisp, and Python (my current favorite). But because I'm not a low level C guru (yet), I looked for things I could contribute to that weren't frightening -- some of the suggestions on the Wiki summer of code page look like they're meant for people already familiar with the wine codebase. That said, I'm interested in picking up the desktop integration areas that wine currently lacks. Working trash, my documents, autorun, xdg menu support (adding start menu items to the K-menu for instance), winebrowser, and icon themes. Basically a good chunk of stuff on the fun projects page. Two questions: 1. My understanding is the mentor organizations get to choose who they want. Is the wine project still interested in someone with my relatively low C/wine code base experience or should I just look elsewhere? 2. Is this something feasible for a proposal? Could it realistically be completed over the summer, say with 10 (insert your realistic number here) hours a week of work? You guys know the code better than I do :)

4 3

Copy Protection & WINE
by Jonathan Wilson June 2, 2005

June 2, 2005

From what I understand, there are 3 ways to do copy protection in WINE (at least for copy protection that needs a kernel driver to work): 1.Implement a WINE implementation of that kernel driver (in the same way various stock windows kernel drivers have been implemented). Problem with this is that there is a big DMCA risk (which is why AFAIK its been rejected) 2.Implement a fake NTOSKRNL that has just the entrypoints for accessing and loading copy protection drivers (the set of kernel calls needed by the copy protection drivers is only a very small subset of the total set of kernel calls and AFAIK none of them are hardware related) or 3.Implement a proper kernel driver loader (i.e. one that would sit in the windows kernel and do the same sort of thing as that ndiswrapper and that ntfs.sys loader do) What is the current state of copy protection work for WINE? Which of these 3 options do the developers intend to follow? (I remember someone posted some actual code for option 2 but I dont remember if anything happened with it)

2 1

Re: fixes for -Wmissing-declarations and -Wwrite-strings warnings
by Pouech Eric DMI AEI CAEN June 2, 2005

June 2, 2005

looking at the patch, I saw something in the code that made me sick: char *audioAutoDetect(void) { [snip] char *driversFound[10]; [snip] return driversFound[0]; [snip] } can someone fix that broken code ? that would be another nice janitorial task to check whether this kind of error exists somewhere else (I'd bet it does) A+

2 1

Re: fixes for -Wmissing-declarations and -Wwrite-strings warnings
by Andreas Mohr June 2, 2005

June 2, 2005

Hi, On Thu, Jun 02, 2005 at 08:31:36PM +0900, Mike McCormack wrote: > ChangeLog: > * fixes for -Wmissing-declarations and -Wwrite-strings warnings Argh, this is what I had done recently but didn't manage to submit yet. (I told in a mail that I had done programs/ and tools/) > -static char *ignored_fstypes[] = { > +static const char *ignored_fstypes[] = { > "devpts", > "tmpfs", > "proc", > @@ -61,7 +61,7 @@ static char *ignored_fstypes[] = { > NULL > }; Imperfect - it should be static const char * const ignored_fstypes[] since otherwise the ignored_fstypes pointer is still non-const (objdump -x) which it doesn't need to be (may mark more memory pages as read-write than necessary). Sure, your objective was to fix all strict compiler warnings which that patch probably did successfully, but why not go that extra mile... Andreas Mohr

2 1

Winelib MFC app crashes after printing
by Eugene Aksenov June 2, 2005

June 2, 2005

Hello, I have a small MFC app ported to winelib which uses MFC compiled with winelib. Really, it is just an App-Wizard generated application. I always have a crash of the application after printing. The page is printed ok but after that the app crashes. I use LPD for printing and my command line from wine is 'lpr -P<myprinter>'. I also try to print without MFC support i.e creating the printer DC by hand etc - the crash is the same, it follows EndDoc() call. There is no crash like this at the same linux configuration using in a 'pure' Win32 simple application without MFC though the code for printing is the same. When i print to file, all is ok. So , my current workaround is printing to a temp file and then send the file to lpr. I use RH9.0, wine20050419. My [spooler] section in config is the default from the wine installation. Did anybody meet a problem like that ? Is it MFC that has some impact here ? Thanks a lot for any hints.

2 2