On 6/26/05, Saulius Krasuckas <[EMAIL PROTECTED]> wrote:
> ChangeLog:
> Saulius Krasuckas <[EMAIL PROTECTED]>
> Link to Image Color Management (ICM) Reference instead of
> irrelevant MSCMS Publishing API docs.
>
>
> Index: templates/en/status_dlls.template
> ==
On 6/26/05, Saulius Krasuckas <[EMAIL PROTECTED]> wrote:
> ChangeLog:
> Saulius Krasuckas <[EMAIL PROTECTED]>
> Link to Image Color Management (ICM) Reference instead of
> irrelevant MSCMS Publishing API docs.
>
Hello Saulius,
After status6 is committed you can look over
able to develop Windows applications without
having to talk to the Microsoft developers.
So in that respect, having the WineLib documentation in French can help
French companies port their Windows applications using WineLib.
There's still the issue of it being very outdated but it's
On Tue, Mar 15, 2005 at 03:36:12PM +0100, Francois Gouget wrote:
> * WineLib User Guide
> José CARRENO
> Yvon BENOIST (proofreading)
> http://fgouget.free.fr/wine/winelib-user.html
I'm not sure it's a good idea to translate this one. First off,
this guide is quite out of date
The Wine documentation has been translated to French by students from
the Insa of Rouen.
The credits for the translation go to:
* Wine User Guide
Romain CONSEIL
Damien GIRAUDEAU
Guillaume LEFEBVRE
Yvon BENOIST (proofreading)
http://fgouget.free.fr/wine/wine
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> On Mon, Mar 14, 2005 at 11:18:40AM -0600, Alexandre Julliard wrote:
> > Log message:
> > Get rid of the remaining registry configuration parameters.
>
> Any plans on getting the global registry back?
Not in its current form, no. We need to ret
On Mon, Mar 14, 2005 at 11:18:40AM -0600, Alexandre Julliard wrote:
> Log message:
> Get rid of the remaining registry configuration parameters.
Any plans on getting the global registry back?
--
Dimi.
On Sat, 12 Mar 2005, Scott Ritchie wrote:
I wanted the Wine documentation to appear on the nice help menus, like
other standard apps. I learned that the way to do this is to write an
OMF file for each document, which scrollkeeper can then look at to find
the metadata about where the document is
Mike Hearn wrote:
Hmm, I don't see why. You realise we can't write to the native registry
yes? So using a native registry with the old code was equivalent to
doing an import each time you started Wine. For the case where you
install under Windows then run under Wine, you only need one import
anyway
On Sun, 13 Mar 2005 19:21, Dmitry Timoshkov wrote:
> "Eric Pouech" <[EMAIL PROTECTED]> wrote:
> > > For asynchronous read operations, hFile can be any handle opened with
> > > the FILE_FLAG_OVERLAPPED flag by the CreateFile function, or a socket
> > > handle returned by the socket or accept functio
On Sun, Mar 13, 2005 at 09:17:08AM +0100, Eric Pouech wrote:
> Also, we miss in the KERNEL32 part some information on
> - 16 bit support (and DOS of course)
> - Global vs local vs heap allocation
Yes, these would be very useful. I'll keep it open then.
--
Dimi.
On Sun, Mar 13, 2005 at 09:13:31AM -0700, Brian Vincent wrote:
> On Sat, 12 Mar 2005 16:57:22 -0800, Scott Ritchie <[EMAIL PROTECTED]> wrote:
> > 1) Create a new directory for all XML documentation at wine/doc. This
> > will also bring us to be more standard.
>
> The k
ularly thrilled to have to change all the documentation every
> couple of years just to follow the so-called standard of the day.
As Mike pointed out already, I don't think it's a big deal to convert
to XML. One benefit would be to get away from the awful DSSSL crap.
With XSLT we at lea
On Sat, 12 Mar 2005 16:57:22 -0800, Scott Ritchie <[EMAIL PROTECTED]> wrote:
> 1) Create a new directory for all XML documentation at wine/doc. This
> will also bring us to be more standard.
The key is that we use Docbook's SGML. Docbook now supports XML and
converting the SGM
Mike McCormack wrote:
You're very quick to accuse.
This is a techical list and we are technical people, so let's have a
technical discussion about the benefits to Wine of the change, rather
than a mud-slinging, name calling flame fest, OK?
I take every thing I said back. I meant in a technical f
On Sun, 2005-03-13 at 16:31 +0200, Boaz Harrosh wrote:
> The tool you propose is not it, as I said in my first post, "Dynamic" is
> the only solution for what I was talking about, i.e. the use of same
> registry.
Hmm, I don't see why. You realise we can't write to the native registry
yes? So usi
Boaz Harrosh wrote:
Well! Above logic just eliminated Wine my friends. If Native dlls and
Registry is a set back on "Free" Wine development, than logic would
follow that, running native Windows applications (Wine) is a set
back/discouragement of Free SW development.
I'm almost sure my words wil
Mike Hearn wrote:
Oh for goodness sake, Alexandre already explained that the whole purpose
of this change was to start on moving the config file into the registry
so we can use winecfg. You know, winecfg, that program that CodeWeavers
don't need because we already have our own? That program which I
Dmitry Timoshkov a écrit :
"Eric Pouech" <[EMAIL PROTECTED]> wrote:
For asynchronous read operations, hFile can be any handle opened with the
FILE_FLAG_OVERLAPPED flag by the CreateFile function, or a socket handle
returned
by the socket or accept function.
which means that ReadFile() only works
"Eric Pouech" <[EMAIL PROTECTED]> wrote:
> >>>For asynchronous read operations, hFile can be any handle opened with the
> >>>FILE_FLAG_OVERLAPPED flag by the CreateFile function, or a socket handle
> >>>returned
> >>>by the socket or accept function.
> >>>
> >>
> >>which means that ReadFile() onl
Mike Hearn wrote:
I think we'd do just as well to provide a little tool you can run on
Windows to watch a software installation and import the registry
entries/files into Wine.
I wrote such a tool once. Do you want me to ask my former employer if he
would mind releasing it?
Shachar
-
On Sun, 2005-03-13 at 13:29 +0200, Boaz Harrosh wrote:
> Well! Above logic just eliminated Wine my friends. If Native dlls and
> Registry is a set back on "Free" Wine development, than logic would
> follow that, running native Windows applications (Wine) is a set
> back/discouragement of Free SW
On Sun, 13 Mar 2005 11:53:01 +0100, Alexandre Julliard wrote:
> There's nothing great about SGML, no argument here; but as far as I
> can tell XML is the same mess except a bit worse. And I can't say I'm
> particularly thrilled to have to change all the documentation ever
Boaz Harrosh wrote:
Well! Above logic just eliminated Wine my friends. If Native dlls and
Registry is a set back on "Free" Wine development, than logic would
follow that, running native Windows applications (Wine) is a set
back/discouragement of Free SW development.
I restrained myself from sayi
Dmitry Timoshkov a écrit :
"Eric Pouech" <[EMAIL PROTECTED]> wrote:
For asynchronous read operations, hFile can be any handle opened with the
FILE_FLAG_OVERLAPPED flag by the CreateFile function, or a socket handle
returned
by the socket or accept function.
which means that ReadFile() only works
Steven Edwards wrote:
I have to agree. Short term being able to load the Windows registry and Windows
system dlls helped Wine but long term it has led to stagnation. Most of the
recent growth in Wine in past few years has been because we are being forced to
not be dependant on a existing Windows in
argument here; but as far as I
can tell XML is the same mess except a bit worse. And I can't say I'm
particularly thrilled to have to change all the documentation every
couple of years just to follow the so-called standard of the day.
--
Alexandre Julliard
[EMAIL PROTECTED]
On Sun, 2005-03-13 at 03:11 -0500, Dimitrie O. Paun wrote:
> On Sat, Mar 12, 2005 at 04:57:22PM -0800, Scott Ritchie wrote:
> > 1) Create a new directory for all XML documentation at wine/doc. This
> > will also bring us to be more standard.
>
> You better check with Ale
"Eric Pouech" <[EMAIL PROTECTED]> wrote:
> > For asynchronous read operations, hFile can be any handle opened with the
> > FILE_FLAG_OVERLAPPED flag by the CreateFile function, or a socket handle
> > returned
> > by the socket or accept function.
> >
> which means that ReadFile() only works on s
Dimitrie O. Paun a écrit :
Does this complete task Documentation/Devel Guide/6 on the TODO list?
not yet IMO. I'd like to re-balance the content of the archi chapter and the one
of the kernel modules chapter (ie move the details of process, DLL and memory
handling from the former to the
Dmitry Timoshkov a écrit :
"Eric Pouech" <[EMAIL PROTECTED]> wrote:
+ File management
+
+ With time, Windows API comes closer to the old Unix paradigm "Everything
+ is a file". Even if it grew better over the years, it's still not 100%
+ there (for example, you cannot use ReadFile() ov
On Sat, Mar 12, 2005 at 04:57:22PM -0800, Scott Ritchie wrote:
> 1) Create a new directory for all XML documentation at wine/doc. This
> will also bring us to be more standard.
You better check with Alexandre first, I doubt he'll go for it.
> 3) We follow the steps at the abo
"Eric Pouech" <[EMAIL PROTECTED]> wrote:
> + File management
> +
> + With time, Windows API comes closer to the old Unix paradigm "Everything
> + is a file". Even if it grew better over the years, it's still not 100%
> + there (for example, you cannot use ReadFile() over
> + a socket h
I wanted the Wine documentation to appear on the nice help menus, like
other standard apps. I learned that the way to do this is to write an
OMF file for each document, which scrollkeeper can then look at to find
the metadata about where the document is and how to index it and such.
The trouble
On Sat, Mar 12, 2005 at 09:29:44PM +0100, Eric Pouech wrote:
> some DocBook cosmetic stuff, and new docu (file management being the most
> important one)
Very nice!
Does this complete task Documentation/Devel Guide/6 on the TODO list?
--
Dimi.
On Sat, 2005-03-12 at 21:57 +0100, Alexandre Julliard wrote:
> And in order to do this we need to get rid of the current registry hacks,
> the first of which is the Windows registry loading code.
Ah OK, I didn't realise this was necessary for winecfg to be activated.
thanks -mike
Mike Hearn <[EMAIL PROTECTED]> writes:
> I'd have to disagree. I am not really convinced this sort of encouragement
> works:
>
> - We have no config file, yet this has apparently not accelerated the pace
> of winecfg development, we just have more confused users
Actually there has been quite a
On Sat, Mar 12, 2005 at 06:51:04PM +, Mike Hearn wrote:
> - We have no config file, yet this has apparently not accelerated the pace
> of winecfg development, we just have more confused users
AFAIK, winecfg is not working with the real registry stuff, so how
would not having a config file ac
On Sat, 12 Mar 2005 10:35:36 -0800, Steven Edwards wrote:
> I have to agree. Short term being able to load the Windows registry and
> Windows
> system dlls helped Wine but long term it has led to stagnation. Most of the
> recent growth in Wine in past few years has been because we are being forced
Hi,
--- Mike McCormack <[EMAIL PROTECTED]> wrote:
> People would moan and complain, but in the end Wine and Wine users would
> be better off, as they would no longer depend on anything but Wine to
> run their Windows software.
I have to agree. Short term being able to load the Windows registry
On 12 Mar 2005 17:04:38 +0100, Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> Mike Hearn <[EMAIL PROTECTED]> writes:
>
> > Is anybody working on this, or will it just be a feature regression until
> > somebody changes the way we use native drives?
>
> Nobody's working on it, so it won't be suppo
Mike Hearn <[EMAIL PROTECTED]> writes:
> Is anybody working on this, or will it just be a feature regression until
> somebody changes the way we use native drives?
Nobody's working on it, so it won't be supported until someone cares
enough to do it. I encouraged a few people to start working on i
Mike Hearn wrote:
On Sat, 12 Mar 2005 16:20:42 +0100, Alexandre Julliard wrote:
There should be an "import existing Windows drive" function in
winecfg, or something along those lines, that would create symlinks to
the Windows install and import the registry.
You mean by moving the native registry
On Sat, 12 Mar 2005 16:20:42 +0100, Alexandre Julliard wrote:
> There should be an "import existing Windows drive" function in
> winecfg, or something along those lines, that would create symlinks to
> the Windows install and import the registry.
You mean by moving the native registry loading code
Mike Hearn <[EMAIL PROTECTED]> writes:
> Hi Alexandre,
>
> What is the thinking behind this patch? If we don't load the Windows
> registry on startup where should it be loaded? Will this code re-appear
> at any point in the future? A significant number of users still expect to
> be able to point
isc : registry.c
> documentation/samples: config
>
> Log message:
> Get rid of the Windows registry loading on startup, this needs to be
> done differently.
>
> Patch: http://cvs.winehq.org/patch.py?id=16565
>
> Old revision New revision Changes Path
--- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> protocol.def itself is the documentation of the protocol, there is no
> need for more. It's pretty much self-explaining anyway, and people who
> can't figure it out by reading the code have no business messing
> aro
by newbies.
protocol.def itself is the documentation of the protocol, there is no
need for more. It's pretty much self-explaining anyway, and people who
can't figure it out by reading the code have no business messing
around with the server protocol. Consider it as the entrance exam for
James Hawkins wrote:
I guess it's not so much that I can't understand it when I read
through the code and read the comments, but that we should document
this so whoever needs to work with the server next won't have to take
time to read through the necessary files to understand it.
It's not comment
Hi James,
> ie why we use do...while(0) loops in SERVER_START_REQ
This is a fairly common idiom in C macros. See here for an explanation:
http://www.everything2.com/index.pl?node_id=1180050
Because it's a common trick, I'm not sure it's worth explaining.
Describing at a high level what SERVER_
anding this correctly.
Some things that would be nice to see in documentation are:
* server protocol design decisions (ie why we use do...while(0) loops
in SERVER_START_REQ as explained by Mike H)
* api like wine_server_add_data, wine_server_call
* adding a server function to protocol.def
* protoco
There are no docs, AFAIK, but I found the file pretty self explanatory
when I read it. Which bits do you find confusing? Maybe we can document
only those parts.
col.def,
> > but I don't know the semantics of this file. Is there any
> > documentation available for this topic, or does anyone have any
> > information that could be added to the docs?
>
> I think you should be looking at
> dlls/advapi32/registry.c::RegLoadKeyW()
>
&g
c, but is not in
> server/protocol.def so, if I'm correct, I can't make a call to
> load_key from ntdll yet. I am trying to add load_key to protocol.def,
> but I don't know the semantics of this file. Is there any
> documentation available for this topic, or does anyone ha
load_key from ntdll yet. I am trying to add load_key to protocol.def,
but I don't know the semantics of this file. Is there any
documentation available for this topic, or does anyone have any
information that could be added to the docs?
--
James Hawkins
Mike Hearn wrote:
One thing I don't understand is why
we put the request in two do...while(0) loops. Won't they just run
once anyway?
It's a portability thing, basically just declaring a new scope, you can
ignore it - do {} while (0) runs the body of the block onc
On Mon, 07 Mar 2005 15:21:45 -0600, James Hawkins wrote:
> I've looked deeper into this and found include/wine/server.h and the
> SERVER_START_REQ define. So this define is a method of communication
> between the client(?) and server?
Yep, pretty much. It sets up some state for the wine_server_
On Mon, 7 Mar 2005 11:51:53 -0600, James Hawkins <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm implementing NtLoadKey, but I can't find any documentation on
> making server requests, ie SERVER_START_REQ, the different tracing
> abilitites such as using fprintf(stderr,..
Hi,
I'm implementing NtLoadKey, but I can't find any documentation on
making server requests, ie SERVER_START_REQ, the different tracing
abilitites such as using fprintf(stderr,...) instead of the known
TRACE, style of code etc. The latter two are not as important to me
because I'
Le lun 14/02/2005 à 04:29, Alexandre Julliard a écrit :
> Vincent Béron <[EMAIL PROTECTED]> writes:
>
> > Those errors are particularly bad as (in the past) it prevented the Wine
> > documentation on winehq to be built for a release.
> >
> > Alexandre, do
Vincent Béron <[EMAIL PROTECTED]> writes:
> Those errors are particularly bad as (in the past) it prevented the Wine
> documentation on winehq to be built for a release.
>
> Alexandre, do you build the docs the same way you compile C files after
> applying a patch, or
Mike said this about my new "helping applications work" page:
>Looks great! I'd suggest putting it in the Documentation section, and
>then linking to it from the appdb page.
This then prompted me to wonder "which documentation section?" This is
kind of confusing:
On Sun, 28 Nov 2004 20:08:41 -0800, Scott Ritchie wrote:
> So, how is this done? I presume there's a freedesktop.org standard for
> these things, as both Gnome and KDE have them in the same way, but
> currently we're not converting the documentation sgml files into these
> h
On Sun, 28 Nov 2004 20:08:41 -0800, Scott Ritchie <[EMAIL PROTECTED]> wrote:
> Coincidentally, this might tie in very well to the desktop integration
> tasks suggested this week. Perhaps we should create a desktop
> integration tasklist or even append it onto the 1.0 todo?
I think it fits better
While making the Debian package, I had to do a special hack to compile
wine's documentation because it's made seperately.
This isn't a really big deal, but what I did realize is that Wine's
documentation doesn't get installed to the help menu now coming standard
o
Mike Hearn a écrit :
Spiffy.
As part of my ongoing quest to make Wine hacking less scary, I've
written some docs on SEH. I'll submit them to the kernel modules section
when I get net access back.
Just a heads up in case anybody else was thinking of covering that topic.
good (I had that in mind t
Spiffy.
As part of my ongoing quest to make Wine hacking less scary, I've
written some docs on SEH. I'll submit them to the kernel modules section
when I get net access back.
Just a heads up in case anybody else was thinking of covering that topic.
Eric Pouech wrote:
As posted on wine-devel, her
On Wed, 6 Oct 2004, Francois Gouget wrote:
I found this one when examining the output of ./tools/winapi/winapi_check.
It turned out to be just a stroke of luck as winapi_check seems to complain
about the documentation of each and every function though I don't understand
what's wrong:
This is interesting information, but where did it come from? Is this
structure described in some MS documentation? If so, does it have the
full layout of the TEB as well?
Log message:
Robert Reif <[EMAIL PROTECTED]>
Document all the structure members up to SessionId in the PEB.
I have completely hand-installed DirectX 9.0c at this time along with
dxdiag.exe and additional DXMedia runtime components along with the
DCOM and several other subsystems from Windows 2000 professional
Well, native DirectX (DirectDraw+Direct3D at least) requires some
kernel/driver support tha
-- codebase introduction/induction documentation, anything? --
Im new to the wine codebase and see several bugs I am wanting to handle,
however my main concern at this immediate time is trying to sort out
cross-compatability issues...
I have completely hand-installed DirectX 9.0c at this
On Sunday 5 September 2004 13:26, Robert Shearman wrote:
> - * Initialise a new RTL_CRITICAL_SECTION.
> + * Initializes a new critical section.
I'm afraid this critical section from your critical section patch
will upset people in the critics' section ;-)
-Hans
On Wed, 2004-07-28 at 10:11, Jeroen Janssen wrote:
> * is it possible to add the date/version in the online wine documentation
> at http://www.winehq.com/site/documentation (for the user, devel docs)
>
> * when exactly are these pages generated? (nightly/daily/?)
The docs are built w
Hi,
I have a few questions:
* is it possible to add the date/version in the online wine documentation
at http://www.winehq.com/site/documentation (for the user, devel docs)
* when exactly are these pages generated? (nightly/daily/?)
best regards,
Jeroen
Wow, go truiken! This sort of stuff is really handy, it's so much easier
to document wierd stuff in the Wine API docs than rely on MSDN and
peoples memories. Good work!
On Mon, 2004-07-12 at 02:44 -0500, [EMAIL PROTECTED] wrote:
> Changelog
>* Added API documentation to most crypt.c functions
Mike Hearn a écrit :
On Fri, 28 May 2004 09:10:22 +0200, Pouech Eric DMI AEI CAEN wrote:
Hi Mike
I've started to revisit the architecture.sgml file, and started to write
also about this matters (and a few others). For coherency reasons, if
you don't mind, I'll reintegrate your bits in the architect
On Fri, 28 May 2004 09:10:22 +0200, Pouech Eric DMI AEI CAEN wrote:
> Hi Mike
> I've started to revisit the architecture.sgml file, and started to write
> also about this matters (and a few others). For coherency reasons, if
> you don't mind, I'll reintegrate your bits in the architecture.sgml file
> Message du 28/05/04 01:35> De : "Mike Hearn" <[EMAIL PROTECTED]>> A : [EMAIL PROTECTED]> Copie à : > Objet : Add documentation on the address space layout in Wine> Mike Hearn <[EMAIL PROTECTED]>> Add documentation on the address space layout in Wine&g
On Wed, 7 Apr 2004, Michael Jacobsen wrote:
> Hi there. This is my first go at submitting a patch. Let's see if it works.
It needs a small s/avalible/available/ and it would be nice to follow
the 2-space indentation used in the rest of the doc. Besides that it
looks good.
Thanks for your contrib
Robert Shearman <[EMAIL PROTECTED]> writes:
> and renamed the variables to Microsoft conventions.
Please don't do that. The variable names don't matter at all for
compatibility, so we don't have to follow the brain-damaged Microsoft
conventions for them.
--
Alexandre Julliard
[EMAIL PROTECTED]
Le mer 31/03/2004 à 11:49, Peter Hanecak a écrit :
> Hello,
>
> while building Wine on "RedHat 9"-like system I encountered two typo in
> Wine documentation which prevented me from "compiling" documentation with
> docbook2html (docbook-utils-0.6.12-5).
The fi
I was planning to do so. ;-)
Chris
On Sunday 28 March 2004 2:19 pm, Andreas Mohr wrote:
> Hi,
>
> On Sun, Mar 28, 2004 at 02:01:28PM -0500, Chris Morgan wrote:
> > * documentation/bugs.sgml, configuring.sgml
> > Chris Morgan <[EMAIL PROTECTED]>
> > Remove
Hi,
On Sun, Mar 28, 2004 at 02:01:28PM -0500, Chris Morgan wrote:
> * documentation/bugs.sgml, configuring.sgml
> Chris Morgan <[EMAIL PROTECTED]>
> Remove references to winecheck from the documentation and insert a TODO that
> mentions that the functionality is to be
Hi,
Just a small contribution. Hey, have to start somewhere.
When doing a 'make htmlpages' the resulting index.html has no ',' between
Q and R for the Index pages. Attached path should fix that.
Cheers,
Paul
--- wine/tools/c2man.pl 2004-02-09 21:44:22.0 +0100
+++ mywine/tools/c2man.pl 2
t; Rafael Wolf reported to me that the links on
> http://www.winehq.org/site/documentation for the Wine User Guide in PDF
> and PostScript format are broken.
>
> Vincent
--
Jeremy Newman <[EMAIL PROTECTED]>
CodeWeavers, Inc.
Hi,
Rafael Wolf reported to me that the links on
http://www.winehq.org/site/documentation for the Wine User Guide in PDF
and PostScript format are broken.
Vincent
CU so that it
doesn't require anything at runtime at all if it is statically linked. I
need to figure that one out and pass along to Wine packagers (except
Ove, I guess, as Debian carries ICU in its official archives).
- Should we not have a BIDI section in documentation?
Do you vulenteer to
- Where is the official place to download the ICU library for support of
BIDI?
- Should we not have a BIDI section in documentation?
- Is there a place on winehq with links to extra needed downloads?
should ICU be there 2?
Free Life
Boaz
On Fri, Mar 12, 2004 at 08:33:32PM +0100, Uwe Bonnes wrote:
> > "Dimitrie" == Dimitrie O Paun <[EMAIL PROTECTED]> writes:
>
> Dimitrie> On Fri, 12 Mar 2004, Uwe Bonnes wrote: WINEDEBUG=+relay wine
> Dimitrie> yourprog.exe
> >> It only works with selected shells...
>
> Dimitri
Ivan Leo Murray-Smith schrieb:
AFAIK
./configure
make depend
make
has never built the docs, at least since I use wine.
Ivan.
I have always used the installer script
AFAIK
./configure
make depend
make
has never built the docs, at least since I use wine.
Ivan.
On Fri, 12 Mar 2004 14:53:18 -0500, Dimitrie O. Paun wrote:
>> Ah, holy shell wars :-)
> yes, finally!!!
Bah, just don your toga and use vino dammit :) problem solved!
On Fri, 12 Mar 2004, Uwe Bonnes wrote:
> Ah, holy shell wars :-)
yes, finally!!!
> An example is worth a lot of explanations. The vanishing wine command line
> option nerved me a long time now. Only today I looked up what can be done to
> start wine with changed variables for that command. For c
> "Dimitrie" == Dimitrie O Paun <[EMAIL PROTECTED]> writes:
Dimitrie> On Fri, 12 Mar 2004, Uwe Bonnes wrote: WINEDEBUG=+relay wine
Dimitrie> yourprog.exe
>> It only works with selected shells...
Dimitrie> s/selected/standard/
Dimitrie> If you have the bad inspiration to
On Fri, 12 Mar 2004, Uwe Bonnes wrote:
> Dimitrie> WINEDEBUG=+relay wine yourprog.exe
>
> It only works with selected shells...
s/selected/standard/
If you have the bad inspiration to us csh instead,
I think you should know how to translate standard
shell idions into your own. It's just stu
>>>>> "Dimitrie" == Dimitrie O Paun <[EMAIL PROTECTED]> writes:
Dimitrie> On Fri, 12 Mar 2004, Uwe Bonnes wrote:
>> Changelog: documentation/wine.man.in Mention the env command to start
>> a command with modified variables
Dimit
On Fri, 12 Mar 2004, Uwe Bonnes wrote:
> Changelog:
> documentation/wine.man.in
> Mention the env command to start a command with modified variables
Why do you need env(1)? What's wrong with:
WINEDEBUG=+relay wine yourprog.exe
--
Dimi.
ceptable?
Alexandre> No, I think it's better to start using the new
Alexandre> mechanism. Otherwise there will be even more confusion about
Alexandre> when you can use the options and when you can't. And really,
Alexandre> typing WINEDEBUG= isn't mu
Uwe Bonnes <[EMAIL PROTECTED]> writes:
> Would a patch extending the wrapper to understand all those old but handy
> options ( --debugmsg , --dll) be acceptable?
No, I think it's better to start using the new mechanism. Otherwise
there will be even more confusion about when you can use the option
> "Alexandre" == Alexandre Julliard <[EMAIL PROTECTED]> writes:
...
Alexandre> ... Start deprecating the --debugmsg option.
Would a patch extending the wrapper to understand all those old but handy
options ( --debugmsg , --dll) be acceptable?
--
Uwe Bonnes[EMAIL PROTECT
201 - 300 of 326 matches
Mail list logo
