Sylvain Petreolle wrote:
> Could we have the first snapshots ?
> winebootup is not in CVS for the moment...
The current version has Alexander Mohr and I. I haven't changed anything
yet, as I have first implemented the neccessary patches in wine directly
and I don't have not that much time right
Could we have the first snapshots ?
winebootup is not in CVS for the moment...
> Is winebootup going to replace wine then, once it is
> finished? Otherwise
> there would be two boot programs doing almost
> similar things and that's
> what I consider a bad design. :)
>
__
Andreas Mohr wrote:
> Hmm, well, winebootup is supposed to execute everything *at once*
> on Wine startup (i.e. check in the wine wrapper script whether this is
> the first wine instance to get started, then run winebootup)
>
> If you don't think this is a good design, then go ahead and change i
On Tue, Feb 26, 2002 at 12:14:15PM +0100, Gerhard W. Gruber wrote:
> David Elliott wrote:
> > Anyway, on a personal note, don't get disheartened that the wine
> > developers don't like you. Believe me, EVERYBODY who has contributed code
> > to Wine has had some code or some ideas frowned upon. J
David Elliott wrote:
> First of all, it'd be nice if you used "Reply All" so I wouldn't have to
> comb through the list to respond.. but no biggie really.
No Problem. I prefer to use the NGs instead, and there I hate to receive
emails about threads I participate in.
> > But one argument was th
On Mon, 25 Feb 2002, David Elliott wrote:
> Err, by "the code to do this" I was still referring to the code that does
> the bootup procedure. And I don't believe that it should be linked to the
> emulator. It can and will have to be linked to winelib (thus making it a
> winelib program) but it
First of all, it'd be nice if you used "Reply All" so I wouldn't have to
comb through the list to respond.. but no biggie really.
On 2002.02.24 09:03 Gerhard W. Gruber wrote:
> David Elliott wrote:
>
> > To really follow the UNIX philosophy you want to put it in a seperate
> > application. Sav
On 2002.02.23 23:49 [EMAIL PROTECTED] wrote:
> On Sat, 23 Feb 2002, David Elliott wrote:
>
> > application. Save yourself a lot of trouble trying to figure out where
> to
> > place a hook in wine and simply write it into a completely seperate
> > program. You can then have wine actually run tha
Andreas Mohr wrote:
> > /programs/
> > is a good neighborhood.
> Sure, and that's why I chose programs/winebootup/.
>
> Well, it's not submitted in its complete form yet, but I'm going
> to continue working on it.
But your wine bootup does much more then just handling the
renaming/deletion of f
David Elliott wrote:
> To really follow the UNIX philosophy you want to put it in a seperate
> application. Save yourself a lot of trouble trying to figure out where to
> place a hook in wine and simply write it into a completely seperate
> program. You can then have wine actually run that prog
On Sat, Feb 23, 2002 at 11:49:43PM -0500, [EMAIL PROTECTED] wrote:
> On Sat, 23 Feb 2002, David Elliott wrote:
>
> > application. Save yourself a lot of trouble trying to figure out where to
> > place a hook in wine and simply write it into a completely seperate
> > program. You can then have w
On Sat, 23 Feb 2002, David Elliott wrote:
> application. Save yourself a lot of trouble trying to figure out where to
> place a hook in wine and simply write it into a completely seperate
> program. You can then have wine actually run that program with a
> CreateProcess call or similar at whate
On 2002.02.22 08:08 Gerhard W. Gruber wrote:
[SNIP]
> That's more my way. :) I want an application that has maximum
> configurability while being as less as intrusive as needed. That's what
> I like about Unix and I don't want to introduce Windows behaviour into
> the Unix world. :)
>
> I'll see
Alexandre Julliard wrote:
> moving it to higher layers, like in a separate app, you have access to
> more functionality; for instance you can popup a confirmation dialog
> or things like that.
That's ok but this can also be done in a seperate module. I don't like
to have multiple programs if it
"Gerhard W. Gruber" <[EMAIL PROTECTED]> writes:
> So why is it neccessary for this to be in a seperate app and are there
> already any plans on how this should have been integrated? Which layer
> would that be that decides this? If the decision is done in a higher
> app, why not just implement it
Alexandre Julliard wrote:
> Well, if you discard all objections as "not real" then of course there
> isn't a real objection. But the two mentioned seem very real to
Sorry, I didn't mean them to be not real. It's only that I doubt that
the check for the existence of a registry key and alternative
"Gerhard W. Gruber" <[EMAIL PROTECTED]> writes:
> Maybe it went a bit unnoticed because of the many mails the licence
> issue generated, or then again, maybe the bootprocedure is not that
> important to most. :) The only response I got was that performance could
> be a consideration, which I thin
17 matches
Mail list logo