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?
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
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
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:[email protected]
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
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
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.
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.
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
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.
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.
