October 2002 - Wine-Devel - list.winehq.org

Re: CxxFrameHandler problem
by John K. Hohm April 11, 2003

April 11, 2003

Alexandre Julliard <julliard(a)winehq.com> wrote: > Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > > > Appended program uses CxxFrameHandler and crashes in wine with builtin > > msvcrt, but not with native. Compile as Release version and include the > MFC > > dll. Can somebody compile for Alexandre? Alexandre, is this a start or do > > you need something complete? > > That's a start, yes, thanks. I'll need a more complete example with > nested try blocks, destructors all over the place, typed exceptions, > etc. to make sure I understand all the compiler internal structures; > but I can at least try to make that simple case not crash... Although this may duplicate effort, I am familiar with several strange combinations of exception handling that I know work with Visual C++ 6.0; I will put them a test program for you. You can never have too many test programs, right?

1 1

SetWindowHookEx
by steve.lustbader＠philips.com Dec. 1, 2002

Dec. 1, 2002

My app uses SetWindowHookEx to install a WH_KEYBOARD_LL hook. Currently, the wine implementation tells me "fixme:hook:set_windows_hook system hook WH_KEYBOARD_LL won't work right" when I try to use it. I'd like to implement this so I can get my app to run, but I'm not sure where to start, since I don't know why it "won't work right." Any hints/suggestions? -Steve

3 5

SIGSEGV in IDirectDrawImpl_EnumDisplayModes
by Matthew Bloch Nov. 28, 2002

Nov. 28, 2002

Apologies for needing some more hand-holding: from Alexander's advice I now have the game linking and beginning to execute. It now gets stuck while executing this piece of C++: --------------------------------------------------------------------------- void tDirectDrawScreen::destroy() { DDSURFACEDESC ddsd; memset(&ddsd,0,sizeof(DDSURFACEDESC)); ddsd.dwSize = sizeof(DDSURFACEDESC); ddsd.dwFlags = DDSD_CAPS; ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE; HRESULT hr = mp_directDraw->CreateSurface(&ddsd, &mp_primarySurface, NULL); // crashes here ... } --------------------------------------------------------------------------- This being the segfault that occurs: --------------------------------------------------------------------------- #0 0x40c92c4c in ?? () #1 0x40f56f5f in User_DirectDraw_EnumDisplayModes (iface=0x403acc00, dwFlags=1086925740, pDDSD=0x808c678, context=0x40c92be8, callback=0x40f55dfc <EnumDisplayModesCallbackThunk>) at ddraw/user.c:373 #2 0x40f55e81 in IDirectDrawImpl_EnumDisplayModes (This=0x40c92be8, dwFlags=1086925900, pDDSD=0x808c678, context=0x40c92a94, cb=0x40c92a94) at ddraw/thunks.c:348 #3 0x4080f9b2 in tDirectDrawScreen::setUpWindowedSurfaces (this=0x808c668) at Source/tDirectDrawScreen.cpp:852 #4 0x4080cf1f in tDirectDrawScreen::initialise (this=0x808c668, fullScreen=false, screenWidth=640, screenHeight=480) at Source/tDirectDrawScreen.cpp:88 #5 0x4080caac in tDirectDrawScreen::tDirectDrawScreen (this=0x808c668, fullScreen=false, screenWidth=640, screenHeight=480) at Source/tDirectDrawScreen.cpp:55 #6 0x4082d76f in InitApp (hInst=0x40620000, nCmdShow=1) at Source/Main.cpp:289 #7 0x4082d8fc in WinMain (hInst=0x40620000, hPrevInst=0x0, lpCmdLine=0x403708ad "", nCmdShow=1) at Source/Main.cpp:322 #8 0x4062509c in __wine_exe_main () from /home/mattbee/Work/Nemesis/LSNClient.exe #9 0x400b3799 in start_process () at ../../scheduler/process.c:564 #10 0x400b76c9 in call_on_thread_stack (func=0x400b3558) at ../../scheduler/sysdeps.c:112 --------------------------------------------------------------------------- Any ideas why this might be happening? -- Matthew Bloch Bytemark Computer Consulting Limited http://www.bytemark.co.uk/ tel. +44 (0) 8707 455026

9 22

GetComputerName() question
by Martin Wilck Nov. 5, 2002

Nov. 5, 2002

Why is GetComputerName() an init function, or in other words, why is it important that HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\ComputerName\\ComputerName be set at registry initialization time (in _allocate_default_keys())? I am asking because GetComputerName() IMO returns the wrong value (FQDN rather than NETBIOS name). A real implementation of GetComputerName() would look for the above value in the Registry and use gethostname() only as a fallback, but currently it's the other way around - why ? Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 8

Re: PATCH: ppc fix 2
by Greg Turner Nov. 4, 2002

Nov. 4, 2002

On Wednesday 30 October 2002 07:22 am, Marcus Meissner wrote: > Hi, > > Just a bad macro. > > ciao, marcus > > Changelog: > Fixed LITTLE_ENDIAN_32_READ macro to at least compile. > > Index: ndr_marshall.c > =================================================================== > RCS file: /home/wine/wine/dlls/rpcrt4/ndr_marshall.c,v > retrieving revision 1.9 > diff -u -r1.9 ndr_marshall.c > --- ndr_marshall.c 29 Oct 2002 23:07:33 -0000 1.9 > +++ ndr_marshall.c 30 Oct 2002 13:21:15 -0000 > @@ -59,8 +59,8 @@ > > #define LITTLE_ENDIAN_32_READ(pchar) \ > (MAKELONG( \ > - MAKEWORD(*(pchar), *((pchar)+1)) \ > - MAKEWORD(*((pchar)+2), *((pchar)+3))) > + MAKEWORD(*(pchar), *((pchar)+1)), \ > + MAKEWORD(*((pchar)+2), *((pchar)+3)))) > #endif > > /* oops! thanks! strange that this compiles for i386 at all. maybe gcc is automagically fixing the macro for some of us? -- gmt "The purpose of government is to rein in the rights of the people" --President Bill Clinton, MTV interview, 1993

2 3

Wine 0.8 TODO v0.1
by Dimitrie O. Paun Nov. 4, 2002

Nov. 4, 2002

This is the initial TODO for Wine 0.8. I know, 0.8 has been released before, but that's ancient history. Whether or not it gets released with this version number is irrelevant. In fact, even if it never becomes a public release, it is an important point to reach toward 0.9, and so if we complete this work, it would have solved its purpose. Now, again, what I mean by 0.8: -- Users can start using Wine -- works well for a fair number of apps -- no MS DLLs required (from real Windows) -- User facing stuff (website, docs, etc.) are in a decent state, to avoid scaring them away What is NOT in 0.8: -- stable server protocol: no binary compatibility -- DLL separation: ditto That being said, this is my initial list. Comments, flames, suggestions, are appreciated. A. WineHQ work 0. Reorganize a bit the navigational menu 1. Add a screenshot link to the homepage 2. Create some really sexy screenshots 3. Rework the FAQ interface (static HTML, a la http://www.dvddemystified.com/dvdfaq.html, all on one page, with a clickable question list at the top) 4. Enlist some 'official' distribution maintainers (at the minimum RedHat, Suse, UnitedLinux, Debian) 5. Create nice page with apps that run virtually flawless They should not require MS dlls, tricks, etc. to run Small explanation, screeshot, optional link to download page, such as Tucows. B. Documentation work Andy, take it away! :) C. Wine configuration 0. Merge configuration into the registry 1. Write control panel applets for editing it 2. Have decent defaults so we can start control panel without prior configuration 3. Have wizard like app to autoconfigure wine (?) 4. Make Wine's DLLs register themselves to avoid manual merging of the winedefault.reg 5. Write .inf script to setup a new Wine installation D. Stabilize utilities 0. Get rid of the init directive from .spec files 1. Make sure the .spec file format is fairly stable 2. Ensure the various utilities' options are stable E. Important fixes Alexandre, what to you see here? -- Dimi.

19 68

Re: So lets say we do it
by Dimitrie O. Paun Nov. 4, 2002

Nov. 4, 2002

On October 31, 2002 04:26 pm, Andreas Mohr wrote: > I wouldn't be 100% against placing a Screenshot link on the main page > - it's a mere 99% only. > But with the current menu infrastructure, I'm about 150% against it. > If we added a separate Screenshots menu item (which, by the way, I don't > think is needed, since we do have that nice About page), > then the whole page would grow overly long. Agreed. I say, let's get some of the content in shape, and worry about the form a wee bit later. BTW, any web-design guys around, that may want to take on this task? -- Dimi.

5 13

Wine securityflaw.
by Peter Andersson Nov. 1, 2002

Nov. 1, 2002

Hello again, (FYI, I took the liberty to change the topic since I started the former thread "How is Win/Dos syscalls implemented in Wine?" which I feel has gone a little bit off-topic) I had some more thoughts on the issue... I believe most wine users trust wine not to touch anything outside of its configured drive space. Malicious Linux/Unix syscalls could be embedded in windows apps and if executed do a great deal of damage. After all checking your app is run whithin Wine is not that hard (reading registry settings for instance). Lets call such an malicious app a wine-virus from now on. At present a wine-virus would even be allowed to fork itself, leaving the wine environment and continue to run even after you shutdown the wineserver, and in some cases even after the user logs out. The virus would now have full access to the system whithin the users permission, doing much greater damage than you expected. The question is...Would you expect that damage from running a windows app in wine, when you know it could be safely run in Windows? In just a few embedded bytes in the code it could remove your home directory in a single syscall. Would you expect that? - I wouldnt. I really love the idea of Wine, and the fact that its working good and rather stable now does mean its gaining popularity and a broader user base, which further IMHO accelerates the wine movement. If wine users were aware of the risks of using wine at present, I believe wine would be used more cautiously. Cant we atleast try implement some protection in wine against these attacks, before something really nasty happens. I do think company policy decissions againt using wine, will do just as much damage to the wine movement as too the free software movement at large. I would, despite my current lack of knowledge, gladly offer my help. But I hope someone more experienced would take the lead. Best Regards, Peter Andersson

18 35

What is a leap second
by György 'Nog' Jeney Nov. 1, 2002

Nov. 1, 2002

While I was looking through dlls/ntdll/time.c I came across the following two comments: "FIXME: Compute the number of leap second corrections here" and "FIXME: get the GMT offset here" What do these mean? nog.

4 9

Versions & mass-appeal
by Dimitrie O. Paun Nov. 1, 2002

Nov. 1, 2002

People, I think everybody here agrees that Wine's biggest problem is the lack of developers. No developers, slow progress, no users, back to no developers. We are in this vicious circle for a while, spinning our wheels like crazy. We've achieved great progress lately, but I hope we all agree that Wine is a vast project that can succeed only with a mass appeal similar to the fueling the development of the Linux Kernel. Why are we in this position? For reasons I will not go into right now, it seems painfully obvious to me that we are suffering from a severe case of Bad Public Image (tm). Whenever I talk to people not intimately familiar with Wine, about our beloved project, I am _always_ treated with the same reaction: a surprised "Really, it works? Hmmm, I thought it was only running Freecell...". Translation: people consider Wine a huge hack that can run (by some strange happenings) some apps, sometimes. It is viewed as unreliable, "freak of nature sideshow"; something (maybe) cool to talk about, but utterly useless. THIS IS OUR PROBLEM. The lack of users follows trivially. We know the above opinion is not true. *I* get constantly amazed by how much progress we've made. Something must be done, and I think there is something to be done. How do we change this state of affairs? Well, people need major events to reevaluate their opinions. Being major, they are by definition few, and so we don't have too many chances. For Wine, these events are the upcoming x.y releases. What I'm trying to say is that we have to prepare properly for them. Here's my concrete proposal for releases: 0.8.x : Wine is usable, we don't guarantee binary compatibility 0.9.x : Wine is usable, and we kinda guarantee binary compatibility 1.0.x : Wine is quite usable, we guarantee binary compatibility I'll define these things more precisely later, but before that, let me explain why we should introduce the 0.8.x series: -- a chance to attract more users into the fold -- Wine is approaching that stage fast -- it's a logical, interim step to 0.9 -- will help us focus Whatever the reason, it's a _logical_ step that we must go through in our journey to 0.9, and from a user's perspective, it makes sense to make it public. There's no point in robbing us of the userbase for a abstract techy goal of binary compatibility. That's the next stage. Criteria for these releases: 0.8.0 -- Wine runs several popular apps well (we're close) -- Web site is updated (e.g. Who's Who, etc) -- Existing docs are up-to-date -- Utilities are close to final form (winebuild, etc.) 0.9.0 -- DLL separation complete -- Server protocol complete 1.0.0 -- Major bugs squashed -- Flawless UI -- Complete docs I'll leave it at that. Comments, flames? -- Dimi.

18 45