Re: [anjuta-devel] Port to Windows

["Arnel A. Borja" <kyoushuu yahoo com>]

Hello,

On Saturday, 13 April, 2013 04:56 AM, Sébastien Granjoux wrote:
> Hi Arnel,
>
>
> Le 11/04/2013 08:31, Arnel A. Borja a écrit :
> > 1. Getting the paths in Windows. Programs in Windows needs to be
> > relocatable, so paths should be calculated at runtime. This could be
> > fixed this way:
> >
> > - Provide some functions that create the paths at runtime. This is what
> > GTK+ uses, though the functions are private since it's used only inside
> > the GTK+ libraries. They are in gtk/gtkwin32.c in the sources. These
> > functions create the paths then store them into static variables so that
> > they could return "const gchar *". Seems like those paths are not freed
> > at all. Glade also do something like this in gladeui/glade-app.c, though
> > GladeApp is a singleton and free the variable when it is freed.
>
> We already have some function in libanjuta to do something similar. 
> The difference is that the return value is a gchar * and should be 
> free by the caller.
>
> GFile* anjuta_util_get_user_data_file (const gchar* path, ...);
> GFile* anjuta_util_get_user_cache_file (const gchar* path, ...);
> GFile* anjuta_util_get_user_config_file    (const gchar* path, ...);
> gchar* anjuta_util_get_user_data_file_path (const gchar* path, ...);
> gchar* anjuta_util_get_user_cache_file_path (const gchar* path, ...);
> gchar* anjuta_util_get_user_config_file_path (const gchar* path, ...);
>
>
> Moreover by using different profiles for Anjuta, I will end with a 
> quite different applications which shouldn't share session directories 
> by example. The profile is set on the command line, at run time, so 
> such directories are known at run time only.
I'm currently looking for the paths of system data files of the plugins 
(/usr/share/anjuta in Linux) instead of the user's data files. I might 
add them as plugin functions so that the returned values don't need to 
be freed everytime they are used. Would it interfere with sessions?

> > 2. forkpty and AnjutaLauncher. I tried porting them to Windows to use
> > g_spawn_async_with_pipes but the following problems arose:
>
> I think that if we use g_spawn_async_with_pipes we don't need forkpty 
> and fcntl, no?
I tried hacking on it again and it seems it is possible :). It is now in 
Bugzilla so you could test them.

> > - Signals are not available in Windows. We could emulate SIGKILL and
> > SIGTERM by forcibly killing a process using TerminateProcess, which will
> > not kill it's child processes. Is this the expected result?
>
> I don't know how it's handle with other programs, is it possible to 
> enumerate all child process. Anyway, I don't think it's too important.
I think it's possible to enumerate child processes, like what the Task 
Manager in Windows do. Killing process might leave the opened files of 
the process half-written though, and if not properly handled, might 
prevent recompilation (Windows doesn't allow deletion of running 
executables).

> > Are there any differences between SIGKILL and SIGTERM, anyway?
>
> Yes, SIGTERM ask the process to stop and the process will stop as soon 
> as possible, while SIGKILL destroy the process potentially keeping 
> some files half written.
TerminateProcess is more like SIGKILL then.

To Johannes, sorry I mixed up SIGKILL and SIGTERM in my previous reply. 
It is actually SIGKILL.


Regards,

Arnel