Re: Unhandled exception in old DOS application
"Medland, Bill" wrote: > > > -Original Message- > > From: M.H.VanLeeuwen [mailto:[EMAIL PROTECTED]] > > Sent: Monday, May 13, 2002 7:33 PM > > To: [EMAIL PROTECTED] > > Subject: Unhandled exception in old DOS application > > > > > > Hi, > > > > I hope this is the correct place to ask... > > > > Up until the 20020411 wine release my old DOS application > > worked well...for the > > last ~2 years. (Thanks all of you!) > > With both 20020411 and 20020509 releases the wine issues an > > Unhandled exception > > report and starts the debugger. > > > > bash-2.05$ wine cardload.exe -- -a340 > > -f"c:\\\winapps\\\winphone\\\cardload.hex" > > Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: > > Warning: unprotecting the first 64KB of memory to allow > > real-mode calls. > > NULL pointer accesses will no longer be caught. > > wine: Unhandled exception, starting debugger... > > err:int:DOSVM_Loop MsgWaitForMultipleObjects returned > > unexpected value. > > > > This application just downloads firmware (cardload.hex) to an > > old ISA card. > > > > What can be done to fix this, where should I begin looking to > > fix it, who > > The first thing I'd do is see which "fix" broke it. That requires getting > the code out of the cvs itself. Basically I do an almost binary search > between when I know it "worked" and when I know it failed and what area of > code was affected. > > >From your post I presume you don't get the code from the cvs. Do you > compile yourself or dowload rpms? All linux apps on my systems except netscape, vmware and acroread are updated by me from src tarballs. This system is an _old_ slackware distribution from floppies many years ago that i've upgraded myself since the original install. (no libc 5 cruft left on this system ;) Guess it's time to learn CVS. Thanks Martin > > Bill
conflicting types for `usleep' in wine/port.h and libwine/port.c
I don't guess we are building libwine.dll on mingw but I was playing
with it just the same when I came to this. Is this to be expected?
gcc -mno-cygwin -c -I. -I. -I../include -I../include -D__MINGW__
-D_WINDOWS -DW
INE_NOWINSOCK -Wall -mpreferred-stack-boundary=2 -D__WINE__
-DDLLDIR="\"/usr/loc
al/lib/wine\"" -D_REENTRANT -o port.o port.c
port.c:65: conflicting types for `usleep'
../include/wine/port.h:299: previous declaration of `usleep'
Port.h:
#ifndef HAVE_USLEEP
int usleep (unsigned int useconds);
#endif /* !defined(HAVE_USLEEP) */
Port.c:
#ifndef HAVE_USLEEP
unsigned int usleep (unsigned int useconds)
{
#if defined(__EMX__)
DosSleep(useconds);
return 0;
#elif defined(__BEOS__)
return snooze(useconds);
#elif defined(HAVE_SELECT)
struct timeval delay;
delay.tv_sec = useconds / 100;
delay.tv_usec = useconds % 100;
select( 0, 0, 0, 0, &delay );
return 0;
#else /* defined(__EMX__) || defined(__BEOS__) || defined(HAVE_SELECT)
*/
errno = ENOSYS;
return -1;
#endif /* defined(__EMX__) || defined(__BEOS__) || defined(HAVE_SELECT)
*/
}
#endif /* HAVE_USLEEP */
"Every revolution was once a thought in one man's mind"
- Ralph Waldo Emerson
Re: Winelib apps and PATH
You have exactly the same idea I had 3 months ago,
but at this moment I thought this wouldn't be
accepted.
And this is so simple to desactivate a builtin app
this way when it's not enough complete.
> My plan is to integrate that with the loadorder and
> builtin dll
> mechanism. So CreateProcess("notepad.exe") would
> load either the
> native notepad.exe or the builtin notepad.so
> transparently depending
> on your config. And the builtin would pretend to be
> loaded from
> c:/windows/system just like dlls, so you wouldn't
> need to configure a
> drive for /usr/local/bin (except if you want to
> launch real Unix
> binaries from there too).
>
> --
> Alexandre Julliard
> [EMAIL PROTECTED]
___
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
Re: Winelib apps and PATH
Joerg Mayer <[EMAIL PROTECTED]> writes:
> While I think that doing something like this should really be done,
> I don't like mixing windows/wine executables and linux (aka native
> os) executables. Maybe some directory like /usr/local/win (or winebin)
> would be better.
My plan is to integrate that with the loadorder and builtin dll
mechanism. So CreateProcess("notepad.exe") would load either the
native notepad.exe or the builtin notepad.so transparently depending
on your config. And the builtin would pretend to be loaded from
c:/windows/system just like dlls, so you wouldn't need to configure a
drive for /usr/local/bin (except if you want to launch real Unix
binaries from there too).
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Winelib apps and PATH
On Tue, May 14, 2002 at 09:44:07PM +0200, Sylvain Petreolle wrote: > Shouldn't we provide a default drive for /usr or > /usrlocal/bin in the config file ? This would solve > the "can't load winedbg 123456" issue that users > usually include in their first reports. > (the debugger cannot be launched because it's in > /usr/local/bin) While I think that doing something like this should really be done, I don't like mixing windows/wine executables and linux (aka native os) executables. Maybe some directory like /usr/local/win (or winebin) would be better. Ciao Jörg -- Joerg Mayer <[EMAIL PROTECTED]> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
talk-through dll
Hello All, I have been reading over the Wine documentation but have not come across this yet. I am interested in having a windows DLL that can access some functions native to Linux. For instance, possibly an application under wine that allows me to add a new user to my Linux box. My guess is that I should be able to write up a windows dll that will talk to Linux. Is this correct? If so then where in the Wine docs can I read more about the specifics of how this can be done? Thanks in advance, Lonnie
Re: configure.in
"Ian D. Stewart" <[EMAIL PROTECTED]> writes: > Is there enough information to implement a new DLL (i.e., is it just > the file references that are out of date), or should I wait for the > rewrite? Adding a dll should be easier now, so you can simply ignore all instructions that don't seem to apply. Basically the steps would be something like: - create directory under dlls/ (16 and 32-bit versions of the dll need to be in the same directory) - create Makefile.in and .spec file in that directory - add Makefile.in in configure.ac AC_CONFIG_FILES list - run make_dlls in dlls/ directory - run configure and make -- Alexandre Julliard [EMAIL PROTECTED]
Re: configure.in
On 2002.05.14 16:06 Alexandre Julliard wrote: > "Ian D. Stewart" <[EMAIL PROTECTED]> writes: > > > I'm walking through 'IMPLEMENTING A NEW DLL' in DEVELOPER-HINTS. > Step > > 3 reads: > > Actually this whole 'implementing a new dll' section is completely > obsolete (like most of the rest of the file), it needs to be rewritten > from scratch, and probably belongs in the Wine developer's guide > instead. Is there enough information to implement a new DLL (i.e., is it just the file references that are out of date), or should I wait for the rewrite? Thanx, Ian
Re: Bug 677 - gather more information on initial bug submission
Andriy Palamarchuk wrote: >I suggest set of changes to use bugzilla more >efficiently and gather more detailed information on >initial bug submission. See: >http://wine.codeweavers.com/bugs/show_bug.cgi?id=677 > >Part of the suggestions is a form to gather detailed >information: >http://wine.codeweavers.com/bugs/showattachment.cgi?attach_id=95 > > > I had a look at the form and it is a thing of beauty. Tony Lambregts
Re: configure.in
"Ian D. Stewart" <[EMAIL PROTECTED]> writes: > I'm walking through 'IMPLEMENTING A NEW DLL' in DEVELOPER-HINTS. Step > 3 reads: Actually this whole 'implementing a new dll' section is completely obsolete (like most of the rest of the file), it needs to be rewritten from scratch, and probably belongs in the Wine developer's guide instead. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Global Wine configuration file not consulted?
Gerald Pfeifer <[EMAIL PROTECTED]> writes: > I noticed that in the absence of ~/.wine/config Wine simply refuses to > start, and truss (on FreeBSD) and trace (on GNU/Linux) reveal that no > other location is consulted for a config file. > > Even explictly Using ETCDIR or `configure --sysconfdir` doesn't seem to > make a difference, even though the documentation indicates otherwise: > > http://www.winehq.com/Docs/wine-pkg/pkg-nonstatic.shtml#WINERC The global configuration is no longer supported at this point, mainly because it doesn't play well with WINEPREFIX. I'm planning to implement a more general solution at some point that will again enable global config files. At the moment if you want that behavior you have to create a symlink from ~/.wine/config to some global config. -- Alexandre Julliard [EMAIL PROTECTED]
Bug 677 - gather more information on initial bug submission
I suggest set of changes to use bugzilla more efficiently and gather more detailed information on initial bug submission. See: http://wine.codeweavers.com/bugs/show_bug.cgi?id=677 Part of the suggestions is a form to gather detailed information: http://wine.codeweavers.com/bugs/showattachment.cgi?attach_id=95 Andriy __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
Winelib apps and PATH
Hi, Testing wine's control.exe replacements makes me show this : If i remove/rename original control.exe, I can do : $ control and I have the Wine Control Panel as it has been installed in /usr/local/bin. But I cannot do: $ wine control wine: cannot find 'control' So if one app calls for example notepad, the app will try to launch "wine notepad" and fail. Shouldn't we provide a default drive for /usr or /usrlocal/bin in the config file ? This would solve the "can't load winedbg 123456" issue that users usually include in their first reports. (the debugger cannot be launched because it's in /usr/local/bin) ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
PATCH: Property sheet bugfixes (Odin)
Changelog: - Center property sheet page during creation (padding) (some applications rely on this behaviour when resizing the page) - Mask away WS_THICKFRAME page style Author: Sander van Leeuwen/Odin ([EMAIL PROTECTED]) Changelog: - Page navigation by resource id Author: Unknown. (Corel Wine or very old Wine version) propsheet.diff Description: Binary data
Re: wwn doesn't work in konq
--- Francois Gouget <[EMAIL PROTECTED]> wrote: > As a > side note, Opera > 6.0beta2 has the same problem wrt. tables as > Konqueror. > So does ie in windows...i have to dl the page and modify the tables to be 78.9% wide for the top 2 tables but the rest are fine... __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
Re: Global Wine configuration file not consulted?
Gerard, thank you for the information. To improve bug handling and insure no bug report will be lost we defined new place to report Wine issues - the Wine bug tracking system. Could you file your report at http://bugs.winehq.com? Regards, Andriy Palamarchuk --- Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > I noticed that in the absence of ~/.wine/config Wine > simply refuses to > start, and truss (on FreeBSD) and trace (on > GNU/Linux) reveal that no > other location is consulted for a config file. > > Even explictly Using ETCDIR or `configure > --sysconfdir` doesn't seem to > make a difference, even though the documentation > indicates otherwise: > > > http://www.winehq.com/Docs/wine-pkg/pkg-nonstatic.shtml#WINERC > > ETCDIR/wine.conf > > This is the global Wine configuration file. It > is only used if > the user running Wine has no local configuration > file. > > % ls -la $ETCDIR/wine.conf > -r--r--r-- 1 root wheel 7616 Mar 11 13:59 > /usr/local/etc/wine.conf > % ls -la /home/pfeifer/.wine/config > ls: /home/pfeifer/.wine/config: No such file or > directory > % wine > Can't open configuration file > /home/pfeifer/.wine/config > > Gerald > -- > Gerald "Jerry" [EMAIL PROTECTED] > http://www.dbai.tuwien.ac.at/~pfeifer/ > > __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com
Global Wine configuration file not consulted?
I noticed that in the absence of ~/.wine/config Wine simply refuses to start, and truss (on FreeBSD) and trace (on GNU/Linux) reveal that no other location is consulted for a config file. Even explictly Using ETCDIR or `configure --sysconfdir` doesn't seem to make a difference, even though the documentation indicates otherwise: http://www.winehq.com/Docs/wine-pkg/pkg-nonstatic.shtml#WINERC ETCDIR/wine.conf This is the global Wine configuration file. It is only used if the user running Wine has no local configuration file. % ls -la $ETCDIR/wine.conf -r--r--r-- 1 root wheel 7616 Mar 11 13:59 /usr/local/etc/wine.conf % ls -la /home/pfeifer/.wine/config ls: /home/pfeifer/.wine/config: No such file or directory % wine Can't open configuration file /home/pfeifer/.wine/config Gerald -- Gerald "Jerry" [EMAIL PROTECTED] http://www.dbai.tuwien.ac.at/~pfeifer/
RE: Unhandled exception in old DOS application
> -Original Message- > From: M.H.VanLeeuwen [mailto:[EMAIL PROTECTED]] > Sent: Monday, May 13, 2002 7:33 PM > To: [EMAIL PROTECTED] > Subject: Unhandled exception in old DOS application > > > Hi, > > I hope this is the correct place to ask... > > Up until the 20020411 wine release my old DOS application > worked well...for the > last ~2 years. (Thanks all of you!) > With both 20020411 and 20020509 releases the wine issues an > Unhandled exception > report and starts the debugger. > > bash-2.05$ wine cardload.exe -- -a340 > -f"c:\\\winapps\\\winphone\\\cardload.hex" > Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: > Warning: unprotecting the first 64KB of memory to allow > real-mode calls. > NULL pointer accesses will no longer be caught. > wine: Unhandled exception, starting debugger... > err:int:DOSVM_Loop MsgWaitForMultipleObjects returned > unexpected value. > > This application just downloads firmware (cardload.hex) to an > old ISA card. > > What can be done to fix this, where should I begin looking to > fix it, who The first thing I'd do is see which "fix" broke it. That requires getting the code out of the cvs itself. Basically I do an almost binary search between when I know it "worked" and when I know it failed and what area of code was affected. >From your post I presume you don't get the code from the cvs. Do you compile yourself or dowload rpms? Bill
