"Rok Mandeljc" rokmandeljc@hotmail.com writes:
I just found out that my dpnhpast patch doesn't apply to current cvs tree (msvcrtd implementation changed Makefile.in and configure). This also mean that dmusic patch I've sent won't apply either. So I'm sending it again, this time in one patch. It *should* apply to (today's) cvs cleanly.
I have applied all the new dlls, but not the dmusic stubs. I think you should try to group related interfaces in the same source file (and possibly merge some of the existing files too), we can't have 40 different source files for a stub dll. A dozen files is the maximum IMO.
I thought whole dmusic would be easier for further implementing if every interface had it's own source file. But since it makes no difference to me, I've put (more or less) related interfaces togehter (note that there're many interfaces in dmusic_misc.c; i didn't find any key to sort them).
I hope it's ok this time :)
I would like to know though, what's wrong with my wineinstall patch I've sent earlier (fake dx files creation)?
"Rok Mandeljc" rokmandeljc@hotmail.com writes:
I would like to know though, what's wrong with my wineinstall patch I've sent earlier (fake dx files creation)?
You should create symlinks like we do for Winelib apps, not empty files. Also there's no reason to prompt the user about it.
----- Original Message ----- From: "Alexandre Julliard" julliard@winehq.com To: "Rok Mandeljc" rokmandeljc@hotmail.com Cc: wine-devel@winehq.com Sent: Tuesday, April 08, 2003 8:43 PM Subject: Re: dmusic stubs
"Rok Mandeljc" rokmandeljc@hotmail.com writes:
I would like to know though, what's wrong with my wineinstall patch I've sent earlier (fake dx files creation)?
You should create symlinks like we do for Winelib apps, not empty files. Also there's no reason to prompt the user about it.
So why don't we create symlinks to all Wine dlls? I think it would fix some messages about older version of commctl (seen at Tiberian Sun and RA2 Installers).
-- Alexandre Julliard julliard@winehq.com
"Rok Mandeljc" rokmandeljc@hotmail.com writes:
So why don't we create symlinks to all Wine dlls? I think it would fix some messages about older version of commctl (seen at Tiberian Sun and RA2 Installers).
It may also break some things; but I guess we could give it a try.
On Tuesday 08 April 2003 02:37 pm, Alexandre Julliard wrote:
"Rok Mandeljc" rokmandeljc@hotmail.com writes:
So why don't we create symlinks to all Wine dlls? I think it would fix some messages about older version of commctl (seen at Tiberian Sun and RA2 Installers).
It may also break some things; but I guess we could give it a try.
I think there might be a bug with symlinks somewhere. When applications try to replace dlls that are really symlinks to $prefix, things go spooky sometimes... anyone else seen that or am I making things up?
"Gregory M. Turner" gmturner007@ameritech.net writes:
I think there might be a bug with symlinks somewhere. When applications try to replace dlls that are really symlinks to $prefix, things go spooky sometimes... anyone else seen that or am I making things up?
Yes, if you have write access to the symlink target then the app can modify the builtin dll, which isn't so good... The right solution would be to do a copy, but copying all the builtins is a bit wasteful.
Hi, On Wednesday 09 April 2003 19:15, Alexandre Julliard wrote:
"Gregory M. Turner" gmturner007@ameritech.net writes:
I think there might be a bug with symlinks somewhere. When applications try to replace dlls that are really symlinks to $prefix, things go spooky sometimes... anyone else seen that or am I making things up?
Yes, if you have write access to the symlink target then the app can modify the builtin dll, which isn't so good... The right solution would be to do a copy, but copying all the builtins is a bit wasteful.
Wouldnt it be better to check in wine if the file accessed is a symlink which dont exist in windows and act accordingly?
My $0.02 Enrico
On Thu, 10 Apr 2003, Enrico Horn wrote: [...]
Yes, if you have write access to the symlink target then the app can modify the builtin dll, which isn't so good... The right solution would be to do a copy, but copying all the builtins is a bit wasteful.
Wouldnt it be better to check in wine if the file accessed is a symlink which dont exist in windows and act accordingly?
Wouldn't that make it impossible to edit a Word document by opening a symlink to it in Word? That would pretty much make smylinks unusable which would be a sad thing. Worse that having to copy the builtin dlls IMO.