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?
It crashed every time when I closed an app, not just
"sometimes" :(
And I think maybe exchange the calling order of
XCloseIM and XCloseDisplay is a better method than
just comments out XCloseIM ( I think this will lead to
some other problems).
--- Alexandre Julliard <julliard(a)wine.codeweavers.com>
wrote:
> ChangeSet ID: 7168
> CVSROOT: /opt/cvs-commit
> Module name: wine
> Changes by: julliard(a)wine.codeweavers.com 2003/01/29
> 19:08:53
>
> Modified files:
> dlls/x11drv : x11drv_main.c
>
> Log message:
> XCloseIM sometimes crashes in Xlib, don't call it.
>
> Patch: http://cvs.winehq.com/patch.py?id=7168
>
> Old revision New revision Changes Path
> 1.67 1.68 +1 -1
> wine/dlls/x11drv/x11drv_main.c
>
>
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Since msvcmaker doesn't support msvc4.0, I'm trying to
install msvc6.0 under wine. (Yeah, I know, I should run it
under windows, but I'm stubborn.)
Interestingly, the setup program puts itself in the background.
This means you have to be careful to check with ps that you don't have
old wines laying around from the last run, and when logging,
you have to make sure all wine processes have exited, else
your log file isn't complete yet.
Unfortunately, setup fails fairly early.
When emulating win9x, it fails before presenting
a dialog box -- with a page fault reading from a file handle
returned from CreateFile. It looks like it's doing an
assembly string search on the Windows file structure pointed
to by the handle! I wonder why. Maybe it was an easy
way to prevent people from running under Wine :-)
We may have to hack wine to make handles be valid pointers;
I wonder what magic bytes setup is looking for there.
When emulating winnt or winxp, it gets a bit further, but dies
with a null pointer access. Oddly enough, adding --debugmsg +relay
lets it proceed. It insists on installing Microsoft VM for Java,
then tries to reboot. Restarting wine d:setup (this time without
--debugmsg) continues properly for a while, but eventually crashes.
Whenever it crashes in winnt/xp, it leaves one or more windowless
wcmd's running the following script:
:Repeat
del "E:\vs60wiz.exe"
if exist "E:\vs60wiz.exe" goto Repeat
del "C:\WINDOWS\DEL4056.BAT"
in a loop, chewing up huge amounts of CPU time.
--
Dan Kegel
Linux User #78045
http://www.kegel.com
well I made it serial.c before I had to run to work. I'm having good luck getting alot of the
objects to compile so far I've only had to kill file.c, ptrace.c, request.c and select.c. Getting
this to build and run on Windows is going to be a bitch =) gettimeofday, fork and all of fd and
networking is going to be the hard part. I've started a tempory header to see what will need to be
implemented in libwine if we want to get wineserver up and running on Windows without cygwin.
Cygwin still really needed get/setthreadcontext (hint, hint)
Thanks
Steven
/* I kill'd file.c, ptrace.c, request.c, select.c
*
* get/set thread context still needs to be done for Mingw and Cygwin
*
* main.c needs a lot of work
*/
/* object.h and async.h */
struct timeval{
int tv_sec;
int tv_usec;
};
/* debugger.c */
#define SIGTRAP NULL
/* file.c - doesnt work */
#define O_NONBLOCK 0
#define POLLIN 0
#define POLLOUT 0
#define POLLIN 0
#define POLLOUT 0
/* main.c */
#define SIGPIPE NULL
#define SIGHUP NULL
#define SIGQUIT NULL
/* named_pipe.c */
#define PF_UNIX NULL
#define SOCK_STREAM NULL
/* object.c */
#define POLLERR 0
#define POLLHUP 0
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
I was sitting at my wife's XP machine with a spare five minutes,
and it suddently came to me that I haven't done enough remote
testing of Wine. So I ran
wcmd
cygwin
startx
ssh -X mybox
ssh mylaptop
wine spyxx.exe
just to see how well wine would work via two ssh hops
on top of x on top of cygwin on top of winxp.
First issue: you can't use the menus with the mouse! Sure, they'll
pop up, but when you move the mouse down to one of the menu items,
the menu goes away. It decides the user really wanted to highlight
the toolbar, or something.
Before you say "Aw, nobody'll do that", consider that LTSP is getting
a lot more popular... and last week a local small business owner I know
asked me to help set up diskless Linux workstations to run his existing
Windows apps.
- Dan
--
Dan Kegel
http://www.kegel.comhttp://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
hi guys, in dlls/icmp/icmp_main.c would it be possible to use
system("/bin/ping..."); if not running as uid 0?, (or using pipes if the
ouput needs to be parsed) as /bin/ping is obviously usually suid root and if
the required options are available as arguments to /bin/ping then wine can
do as requested without running as root, this would be useful to me with
something im working on.
if you guys do consider it a possibility, i would be willing to research it
and write the patch, id just like the go-ahead from you :) if you can think
of any other way round it, id be greatful to hear your suggestions.
_________________________________________________________________
Worried what your kids see online? Protect them better with MSN 8
http://join.msn.com/?page=features/parental&pgmarket=en-gb&XAPID=186&DI=1059
Here is the list of Wine Static and Shareable Files
after some updates. Same as before if you see something
that's wrong could you let me know.
Tom
-----------
-- = files that are listed in this Doc but are not installed on my system.
* = files are in this Doc and on my system
@ = files that are on my system but not in the Doc
# = files that are not in the Doc or on my System ( wineboot ) will be
in future releases ?
-- dosmod : Deleted as of Jan 2001.
-- fnt2bdf : Discussed on Wine-Devel ( practically obsolete )
@ notepad : The windows Notepad replacement
@ progman : Program Manager for WINE.
@ regedit : A tool to edit your regestory or for exporting a windows
registory to Wine.
@ regsvr32 : A program to register .DLL's and .OCX files.
@ uninstaller: A Winelib program to uninstall installed Windows programs.
@ wcmd : Wine's command line interpreter
@ widl : Wine IDL compiler
* wine : The main Wine executable. This program will load a Windows
binary and run it, relying upon the Wine shared object libraries.
# wineboot : A Winelib application that's executed by Wine on startup of
the first wine process of a particular user.
wineboot won't automatically run when needed. Currently you have to
manually run it after you install something.
A list of what it currently does.
* wininit.ini processing
* registry RenameFiles entries
* RunServices* / RunOnce* / Run registry keys
-- winebootup : Now wineboot......
* winebuild : Winebuild is a tool used for Winelib applications (and by
Wine itself) to allow a developer to compile a .spec file into a .spec.c
file.
* wineclipserv : The Wine Clipboard Server is a standalone XLib
application whose purpose is to manage the X selection when Wine exits.
@ wineconsole : a console program for wine, For running CUI executables
(Windows console programs), use wineconsole instead of wine run).
Not using wineconsole for CUI programs will only provide very limited
console support, and your program might not function properly.
* winedbg : Winedbg is the Wine built in debugger.
@ winedump : A NE and PE file dumper
@ winefile : A clone of the win3x filemanager
@ winegcc/wineg++: Wrappers for gcc/g++ respectively, to make them
behave as MinGW's gcc. Used for porting app's over to winelib.
* winelauncher : A wine wrapper shell script that intelligently handles
wine invocation by informing the user about what's going on,
among other things. To be found in tools/ directory. Use of this wrapper
script instead of directly using wine is strongly encouraged,
as it not only improves the user interface, but also adds important
functionality to wine, such as session bootup/startup actions.
If you intend to use this script, then you might want to rename the wine
executable to e.g. wine.bin and winelauncher to wine. the
WINECONFDIR/config file.
winemaker : Winemaker is a perl script which is designed to help you
bootstrap the conversion of your Windows projects to Winelib. In order
to do thisit will go analyze your
code, fixing the issues listed above and generate autoconf-based Makefiles.
@ winemine : A clone of "Windows Minesweeper"
@ winepath : Specifies the path(s) in which to search for builtin dlls
and Winelib applications.
* wineserver : The Wine server is critical to Wine; it is the process
that coordinates all shared Windows resources.
-- winesetup : This is a Tcl/Tk based front end that provides a user
friendly tool to edit and configure the WINECONFDIR/config file.
* wineshelllink : This shell script can be called by Wine in order to
propagate Desktop icon and menu creation requests out to a GNOME or KDE
(or other Window Managers).
@ winewrap : Takes care of linking winelib applications. Linking with
winelib is a complex process, winewrap makes it simple.
@ winhelp : For viewing windows help files
* wmc : Wine Message Compiler it allows Windows message files to be
compiled into a format usable by Wine.
* wrc : Wine Resource Compiler. It allows Winelib programmers (and Wine
itself) to compile Windows style resource files into a form usable by Wine.
Tom Wickline wrote:
> Tony Lambregts wrote:
>
>> I don't think it is nessasary for a configure or shell script for
>> this. I think we can just include it. Declaring it as an entity and
>> wraping it in <programlisting> _should_ work. Tom: you can try this
>> your self or if you want/need some help with this I'll see what I can
>> do.
>>
>
Declaring the sample config as an entity is as easy as the following patch.
Index: wine-pkg.sgml
===================================================================
RCS file: /home/wine/wine/documentation/wine-pkg.sgml,v
retrieving revision 1.1
diff -u -r1.1 wine-pkg.sgml
--- wine-pkg.sgml 19 Jan 2001 20:58:37 -0000 1.1
+++ wine-pkg.sgml 26 Jan 2003 18:02:24 -0000
@@ -5,8 +5,8 @@
%authors;
<!entity packaging SYSTEM "packaging.sgml">
+<!entity config SYSTEM "samples/config">
]>
<book id="index">
-----
After making that change you can include the config file anywhere you
like by using the directive &config;
Getting around the <wineconf> problem is another problem however. It
looks to me that this wineconf could just as easily been surrounded by
stars or braces or whatever since getting rid of the lines does not seem
to have affected any of my programs. If this is the case then getting
rid of <> and replacing them with something else is the (easiest) solution.
If we cannot replace the <> around wineconf the burning question for me
is what is the directive to tell the make process ignore <wineconfig>
Does anyone have an idea? Vincent...?
--
Tony Lambregts
On Thursday 30 January 2003 10:44 am, Ove Kaaven wrote:
> This one is sure to give Greg something to work with...
looks very interesting, indeed.
> all of this was
> implemented in a bit of a hurry, but since it's based on my research, it
> should be a good starting point in understanding how Microsoft's NDR
> engine works. It doesn't properly implement marshalling alignment or
> memory sizing, may not handle a number of fringe cases, does not conform
> to the DCE RPC wire protocol (mostly because I don't have a description of
> it... where did you find it, Greg?), and probably needs some cleanup, but
I think, I had to sign away my firstborn to OpenGroup for it. If you feel
like spending money /and/ signing away your firstborn, this looks like the
definitive OpenGroup DCE package:
http://www.opengroup.org/products/publications/catalog/t151x.htm
and here is some free-as-in-beer RPC 1.1 stuff:
http://www.opengroup.org/products/publications/catalog/c706.htm
Where, exactly, I got what I have is a bit of a mystery to me :( It looks
like it started its journey as postscript so perhaps it's part of the DCERPC
source tarball? My old box is booted into the Operation Flashpoint Operating
System... er... Windows, I mean... so I can't dig it out from my ext3
partition right now.
In your previous patch you mentioned the possibility of a merge situation
between us. Indeed, this is probably the case, but it's minor. I've been
real busy lately with work, and other non-wine things, so I haven't been
forging ahead at my usual clip. There's not a whole lot floating around in
my tree that hasn't gone out to wine-patches ATM.
-gmt
