Re: crtdll (fopen and friends)
On Mon, Aug 14, 2000 at 10:46:13AM +, Eric Pouech wrote: > > WINELIB still uses the current UNIX directory. > whaot WineLib programs are also chdir:ed to '/'... Err. I thought you added a patch that changed the current directory back. Sorry. And yes, it probably needs a better solution. Ciao, Marcus
Re: crtdll (fopen and friends)
> WINELIB still uses the current UNIX directory. whaot WineLib programs are also chdir:ed to '/'... A+ -- --- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle
RE: crtdll (fopen and friends)
> Alexandre Julliard wrote:
> > The right fix IMO is to make chdir() follow
> SetCurrentDirectory(), so
> > that the Unix and Windows curdirs are always in sync. This will
> > require some hacking in the 16-bit task switching (since the 16-bit
> > curdir is per-task, not per-process). Maybe in the meantime
> we should
> > remove the chdir("/"), it seems to cause more problems than
> it fixes;
> > and maybe this will encourage Marcus to implement the right
> solution ;-)
Probably. Personally, I was suprised that you let this hack in. :-)
> One problem with this is that DOS/Windows keeps the current
> directory on a per
> drive basis (at least from a user interface point of view,
> don't know how it is
> implemented internally). Of course since you also know the
> current (aka
> default) drive as well as the current directory you can
> change the current
> UNIX dir when the drive is changed.
This is a question about how relative and absolute paths
are resolved, not an issue about which is the current
directory.
Each thread has one and only one current directory.
> However I could see this
> causing problems
> if a process's current directory is a CD-ROM drive it will prevent the
> CD-ROM from being unmounted. That is both good and bad.
> Under DOS it is
> perfectly valid to eject the CD-ROM even if you are on that
> drive. Under
> Windows it will generally give you a message about the drive
> being in use and
> ask if you want to eject it anyway.
Whether this should be permitted or not is IMHO policy which
should be determined for each system by the system administrator,
since allowing this is potentially dangerous (OK for a CD-ROM
or other read only devices not much can happen but still).
However I'm not sure this a matter of Wine policy, I think
it lies more in the direction of the policy of Unix system.
Wine must of course gracefully handle the case when the directory
disappears under our feet because of forced unmounting of a
mountpoint, but that is a different issue.
> I am not exactly sure how to deal with this extremely screwed
> up behavior. Of
> course that is the story of Wine so what else is new.
I'm not either, however I'm inclined to believe that we really
can't solve this problem internally in Wine in any sane way.
The current Windows directory and the current Windows directory
must be syncronized. BTW, is the "current" syncronization
race free? (No, I haven't checked).
Re: crtdll (fopen and friends)
> One problem with this is that DOS/Windows keeps the current directory on a per > drive basis (at least from a user interface point of view, don't know how it is > implemented internally). Of course since you also know the current (aka > default) drive as well as the current directory you can change the current > UNIX dir when the drive is changed. However I could see this causing problems > if a process's current directory is a CD-ROM drive it will prevent the > CD-ROM from being unmounted. That is both good and bad. Under DOS it is > perfectly valid to eject the CD-ROM even if you are on that drive. Under > Windows it will generally give you a message about the drive being in use and > ask if you want to eject it anyway. > I am not exactly sure how to deal with this extremely screwed up behavior. Of > course that is the story of Wine so what else is new. This problem is solved at least for the emulator. Current directory state is maintained by WINE, the UNIX working directory is always /. (So Diablo2 can change CDs ;) WINELIB still uses the current UNIX directory. Ciao, Marcus
Re: crtdll (fopen and friends)
Alexandre Julliard wrote:
> Eric Pouech <[EMAIL PROTECTED]> writes:
>
> > all winelib programs exhibit this
> > I sent a few weeks ago a patch that solved it (in fact partly,the 'current'
> > dir had to be mapped onto a DOS drive, as defined in ~/.winerc)
> > but, Alexandre didn't commit it yet (didn't like it ?)
>
> The right fix IMO is to make chdir() follow SetCurrentDirectory(), so
> that the Unix and Windows curdirs are always in sync. This will
> require some hacking in the 16-bit task switching (since the 16-bit
> curdir is per-task, not per-process). Maybe in the meantime we should
> remove the chdir("/"), it seems to cause more problems than it fixes;
> and maybe this will encourage Marcus to implement the right solution ;-)
>
One problem with this is that DOS/Windows keeps the current directory on a per
drive basis (at least from a user interface point of view, don't know how it is
implemented internally). Of course since you also know the current (aka
default) drive as well as the current directory you can change the current
UNIX dir when the drive is changed. However I could see this causing problems
if a process's current directory is a CD-ROM drive it will prevent the
CD-ROM from being unmounted. That is both good and bad. Under DOS it is
perfectly valid to eject the CD-ROM even if you are on that drive. Under
Windows it will generally give you a message about the drive being in use and
ask if you want to eject it anyway.
I am not exactly sure how to deal with this extremely screwed up behavior. Of
course that is the story of Wine so what else is new.
-Dave
Re: crtdll (fopen and friends)
Eric Pouech <[EMAIL PROTECTED]> writes:
> all winelib programs exhibit this
> I sent a few weeks ago a patch that solved it (in fact partly,the 'current'
> dir had to be mapped onto a DOS drive, as defined in ~/.winerc)
> but, Alexandre didn't commit it yet (didn't like it ?)
The right fix IMO is to make chdir() follow SetCurrentDirectory(), so
that the Unix and Windows curdirs are always in sync. This will
require some hacking in the 16-bit task switching (since the 16-bit
curdir is per-task, not per-process). Maybe in the meantime we should
remove the chdir("/"), it seems to cause more problems than it fixes;
and maybe this will encourage Marcus to implement the right solution ;-)
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: crtdll (fopen and friends)
Ove Kaaven wrote: > 1. The app assumes the current directory to be the dir I start the > program from, but for whatever reason, the current directory is / (the > root directory), so it's not easy for the app to find the files... > 2. Some of the datafiles contains (relative) paths to other files, and > these paths use backslashes, the libc version of fopen() is unhappy about > those, and I don't like changing those files... all winelib programs exhibit this I sent a few weeks ago a patch that solved it (in fact partly,the 'current' dir had to be mapped onto a DOS drive, as defined in ~/.winerc) but, Alexandre didn't commit it yet (didn't like it ?) A+ -- --- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle
Re: crtdll (fopen and friends)
Uwe Bonnes <[EMAIL PROTECTED]> writes: > will this allow Relay and Snoop Debugging on winelibe executables too? Yes. And it should also allow relay debugging of inter-dll calls between two builtin dlls. -- Alexandre Julliard [EMAIL PROTECTED]
Re: crtdll (fopen and friends)
Alexandre Julliard writes: > Bertho Stultiens <[EMAIL PROTECTED]> writes: > > > How are you implementing this? Just curious because I was working on the > > same subject... > > The idea is that winebuild gets the list of unresolved symbols by > running nm -u on an intermediate object file, and then dlopens each > imported dll and goes through the export table to resolve symbols. It > then generates a list of jmp instructions and a Windows-format import > table. Later on it could also resolve symbols against PE format dlls > so that we could link apps directly against native Windows dlls. > > Anyway, here's what it looks like at the moment: > Hallo, will this allow Relay and Snoop Debugging on winelibe executables too? Bye Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: crtdll (fopen and friends)
Bertho Stultiens <[EMAIL PROTECTED]> writes:
> How are you implementing this? Just curious because I was working on the
> same subject...
The idea is that winebuild gets the list of unresolved symbols by
running nm -u on an intermediate object file, and then dlopens each
imported dll and goes through the export table to resolve symbols. It
then generates a list of jmp instructions and a Windows-format import
table. Later on it could also resolve symbols against PE format dlls
so that we could link apps directly against native Windows dlls.
Anyway, here's what it looks like at the moment:
Index: configure.in
===
RCS file: /home/wine/wine/configure.in,v
retrieving revision 1.146
diff -u -r1.146 configure.in
--- configure.in2000/08/01 00:27:35 1.146
+++ configure.in2000/08/07 20:43:03
@@ -473,29 +473,32 @@
dnl Check for working dll
LDSHARED=""
+LDDLL=""
if test "$LIBEXT" = "so"
then
AC_CACHE_CHECK("whether we can build a Linux dll",
ac_cv_c_dll_linux,
[saved_cflags=$CFLAGS
- CFLAGS="$CFLAGS -fPIC -shared -Wl,-soname,conftest.so.1.0"
+ CFLAGS="$CFLAGS -fPIC -shared -Wl,-soname,conftest.so.1.0,-Bsymbolic"
AC_TRY_LINK(,[return 1],ac_cv_c_dll_linux="yes",ac_cv_c_dll_linux="no")
CFLAGS=$saved_cflags
])
if test "$ac_cv_c_dll_linux" = "yes"
then
LDSHARED="\$(CC) -shared -Wl,-soname,\$(SONAME),-rpath,\$(libdir)"
+LDDLL="$LDSHARED,-Bsymbolic"
else
AC_CACHE_CHECK(whether we can build a UnixWare (Solaris) dll,
ac_cv_c_dll_unixware,
[saved_cflags=$CFLAGS
-CFLAGS="$CFLAGS -fPIC -Wl,-G,-h,conftest.so.1.0"
+CFLAGS="$CFLAGS -fPIC -Wl,-G,-h,conftest.so.1.0,-B,symbolic"
AC_TRY_LINK(,[return 1],ac_cv_c_dll_unixware="yes",ac_cv_c_dll_unixware="no")
CFLAGS=$saved_cflags
])
if test "$ac_cv_c_dll_unixware" = "yes"
then
LDSHARED="\$(CC) -Wl,-G,-h,\$(libdir)/\$(SONAME)"
+ LDDLL="$LDSHARED,-B,symbolic"
else
AC_CACHE_CHECK("whether we can build a NetBSD dll",
ac_cv_c_dll_netbsd,
@@ -507,6 +510,7 @@
if test "$ac_cv_c_dll_netbsd" = "yes"
then
LDSHARED="ld -Bshareable -Bforcearchive"
+LDDLL="$LDSHARED"
fi
fi
fi
@@ -551,6 +555,7 @@
AC_SUBST(DLL_LINK)
AC_SUBST(DLLFLAGS)
AC_SUBST(LDSHARED)
+AC_SUBST(LDDLL)
AC_SUBST(LIBEXT)
dnl Check for reentrant libc
Index: dlls/Makedll.rules.in
===
RCS file: /home/wine/wine/dlls/Makedll.rules.in,v
retrieving revision 1.6
diff -u -r1.6 Makedll.rules.in
--- dlls/Makedll.rules.in 2000/08/03 00:04:24 1.6
+++ dlls/Makedll.rules.in 2000/08/07 20:43:03
@@ -4,7 +4,6 @@
# MODULE : name of the main module being built
# SOVERSION: version of the .so file
# ALTNAMES : alternate names for this dll (optional)
-# IMPORTS : dlls to import (optional)
# EXTRALIBS: extra libraries to link in (optional)
#
# plus all variables required by the global Make.rules.in
@@ -12,11 +11,13 @@
DEFS = @DLLFLAGS@ -D__WINE__
LIBEXT = @LIBEXT@
-LDSHARED = @LDSHARED@
+LDDLL = @LDDLL@
SONAME = lib$(MODULE).so
-IMPORTLIBS = $(IMPORTS:%=$(DLLDIR)/lib%.$(LIBEXT))
ALLNAMES = lib$(MODULE).so $(ALTNAMES:%=lib%.so)
-SPEC_SRCS = $(MODULE).spec $(ALTNAMES:%=%.spec)
+SPEC_SRCS = $(ALTNAMES:%=%.spec)
+MAIN_SPEC = $(MODULE).spec
+
+IMPORTLIBS = $(IMPORTS:%=$(DLLDIR)/lib%.$(LIBEXT))
all: lib$(MODULE).$(LIBEXT) $(ALTNAMES:%=lib%.$(LIBEXT))
@@ -24,21 +25,28 @@
# Rules for .so files
-lib$(MODULE).so.$(SOVERSION): $(OBJS) Makefile.in $(TOPSRCDIR)/Make.rules.in
- $(LDSHARED) $(OBJS) -o $@ -L$(DLLDIR) $(IMPORTS:%=-l%) $(EXTRALIBS)
+ALL_OBJS = $(OBJS) $(MAIN_SPEC).o
+lib$(MODULE).so.$(SOVERSION): $(ALL_OBJS) Makefile.in $(TOPSRCDIR)/Make.rules.in
+ $(LDDLL) $(ALL_OBJS) -o $@ -L$(DLLDIR) $(IMPORTS:%=-l%) -L$(TOPOBJDIR) -lwine
+-lwine_unicode $(EXTRALIBS) $(LIBS)
+
$(ALLNAMES): lib$(MODULE).so.$(SOVERSION)
$(RM) $@ && $(LN_S) lib$(MODULE).so.$(SOVERSION) $@
# Rules for .a files
-lib$(MODULE).a: $(OBJS) Makefile.in $(TOPSRCDIR)/Make.rules.in
+lib$(MODULE).a: $(ALL_OBJS) Makefile.in $(TOPSRCDIR)/Make.rules.in
$(RM) $@
- $(AR) $@ $(OBJS)
+ $(AR) $@ $(ALL_OBJS)
$(RANLIB) $@
$(ALTNAMES:%=lib%.a): lib$(MODULE).a
$(RM) $@ && $(LN_S) lib$(MODULE).a $@
+
+# Rules for main spec file
+
+$(MAIN_SPEC).c: $(MAIN_SPEC) $(MODULE).o $(BUILD)
+ LD_LIBRARY_PATH="$(TOPOBJDIR):$$LD_LIBRARY_PATH" $(BUILD) @DLLFLAGS@ -o $@ -L
+$(DLLDIR) -sym $(MODULE).o -spec $(MODULE).spec
# Rules for checking that no imports are missing
Index: include/builtin32.h
===
RCS file: /home/wine/wine/include/builtin32.h,v
retrieving revision 1.10
diff -u -r1.10 builtin32.h
--- include/builtin32.h 2000
Re: crtdll (fopen and friends)
Alexandre Julliard wrote: > The idea is once we get import tables in builtin dlls (real soon now) > you can import dlls from your app spec file and the dll symbols will > be used before normal ELF linking. So if your app makes calls to > fopen() and you import crtdll, fopen() will automagically resolve to > the crtdll version. How are you implementing this? Just curious because I was working on the same subject... Greetings Bertho
Re: crtdll (fopen and friends)
Ove Kaaven <[EMAIL PROTECTED]> writes: > So how were we supposed to make Winelib apps use the crtdll equivalents of > fopen() and friends cleanly again? The idea is once we get import tables in builtin dlls (real soon now) you can import dlls from your app spec file and the dll symbols will be used before normal ELF linking. So if your app makes calls to fopen() and you import crtdll, fopen() will automagically resolve to the crtdll version. The other issue is that if you import crtdll you then need to compile with crtdll-compatible include files so that all types are defined correctly. This shouldn't matter for fopen() though. -- Alexandre Julliard [EMAIL PROTECTED]
Re: crtdll (fopen and friends)
Ove Kaaven wrote:
> Had you figured out how we're going to call Winelib routines instead of
> libc routines when it comes to functions like fopen() and friends? The
> Winelib app I'm experimenting with does fopen() to open some data files,
> but there are a few problems...
We need to add something like:
#ifdef WINELIB
#define fopen CRTDLL_fopen
.
{Rest of CRTDLL functions handled similarly}
.
#endif
To crtdll.h and include it from windows.h.
-Gav
--
Gavriel State
CEO
TransGaming Technologies Inc.
[EMAIL PROTECTED]
