Re: [AD] al_set_win_dll_path |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 2011-07-27, Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> On Wed, Jul 27, 2011 at 5:13 AM, Elias Pschernig
> <elias.pschernig@xxxxxxxxxx> wrote:
> > al_set_standard_path(int id, ALLEGRO_PATH *path)?
> >
> I thought about recommending that before when we had the long
> discussions. Maybe I did, I dunno.
>
> It's probably only useful with ALLEGRO_RESOURCES_PATH, but ultimately
> I think I decided that the programmer might as well just create a
> wrapper function like get_path() around ALLEGRO_RESOURCES_PATH and his
> own UNIX_CONFIGURE_DATA_PATH compile time option.
>
> Anyway, all that is kind of a side topic. But maybe there is something here.
>
> There could be something like ALLEGRO_LIBRARY_PATH that is writable,
> but you'd almost have to then add support for multiple paths for a
> single id, via al_get_nth_standard_path(int id, int n).
>
> I think I would prefer the following:
>
> * roll back the change to Windows that prevents DLL hijacking. Does it
> really matter?
I think so. Most likely there aren't any Allegro-based programs which
are popular enough for any malware authors to target, but it's not
outside the realm of possibility.
>
> * set the PATH/LD_LIBRARY_PATH environment variable yourself, and let
> Allegro automatically pick that up.
The main problem is loading DLLs from the _current_ directory, so it
should be relatively safe to load from the PATH (excluding the current
directory). I can't remember why I didn't implement that; possibly
because it requires more work.
> If you don't want to disable the DLL hijack completely, you could do
> something like:
>
> c = al_get_system_config();
> al_set_config_value(c, "windows", "use_sys_path_for_dlls", "1");
>
> And failing that suggestion:
>
> c = al_get_system_config();
> al_set_config_value(c, "path", "library", "c:/foo/bar");
>
> And failing that suggestion:
>
> al_set_plugin_search_path(ALLEGRO_PATH *path)
I liked the suggestion for setting the exename explicitly.
Presumably the Python wrapper could set that to
the user's game.py, and DLLs could be placed next to that.
Peter