Re: [anjuta-devel] Port to Windows

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

Hello,


On Thursday, 11 April, 2013 10:03 PM, Johannes Schmid wrote:
> static const gchar*
> anjuta_plugin_get_data_dir (AnjutaPlugin' plugin)
>
> It should be freed when the plugin is destroyed. Actually we could just
> replace the current #defines by a call to that function to make it easier
> to port. But in *nix this function should use the paths as given by the
> current Makefile.am while it may use something else on win32 (maybe
> https://developer.gnome.org/glib/2.35/glib-Windows-Compatibility-Functions.html).
Okay, I will implement it like this then.
> > - fcntl is not available in Windows. Also, pipes cannot be non-blocking,
>
> Really? The documentation about g_spawn_async doesn't say anything about
> blocking on Windows and GIOChannel does neither (apart from that GLib
> implemenets a thread to support async reading).

Sorry, I'm getting confused on Windows because I can't find an 
equivalent for O_SYNC, while Windows pages in MSDN calls overlapping 
(non-blocking in Unix) "asynchronous". I also thought this is the case 
because according to MSDN non-blocking mode should be set during 
creation of the pipe, which happens inside GLib.

I just used the flags of GIOChannel to set non-blocking with O_SYNC only 
used in Unix by calling fcntl.Seems like Windows have ioctlsocket which 
is used by GLib for setting the non-blocking flag.

Is setting O_SYNC really necessary?

> > - 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? Are there
> > any differences between SIGKILL and SIGTERM, anyway? Also we could not
> > tell if a process was forcibly killed or it exited normally since the
> > autotools plugin checks the signals so that it will know how the build
> > was cancelled, though we may assign some special exit codes when we call
> > TerminateProcess.
> Probably the best sulution. There is a difference between SIGKILL and
> SIGTERM (see man kill) but it probably doesn't matter here too much. It
> would be clever to assign an exit code if we killed the process though.
SIGTERM is the one closest to calling TerminateProcess in Windows.I will 
look
for a good exit code then.

> > - Shell scripts. Windows do not support shell scripts, and g_spawn_*
> > will not be able to find them (since they are not recognized as
> > executable by Windows). I created a program to fake scripts temporarily;
> > it will look for the scripts in PATH then check the shebang to know what
> > interpreter to spawn. This also means we would depend to sh or bash (not
> > sure if bash is available in Windows) to run scripts like autogen.sh,
> > configure, autoconf and automake. I might merge the code of this program
>
> > later to AnjutaLauncher.
> Looks good in general. Isn't there a generic sultion to that problem on
> windows?
There's an environment variable in Windows which says which file extensions
are executable, but with that we could only handle scripts with a file
extension (autogen.sh will work but not configure, autoconf or 
automake). Also
I think messing with system-wide environment variables in Windows should be
avoided, because it could easily break the system (viruses do these, and 
we might
be flagged as a virus by an antivirus).
> > - Add application/x-ext-* to each real mime type in each plugins. For
> > example change the MimeTypes value of the plugin file of
> > language-support-vala from "text/x-vala" to
> > "text/x-vala;application/x-ext-vala;application/x-ext-vapi".
> > g_content_type_* will still not work.
> I would do this but probably add an extra line for WindowMimeTypes=...
> because it might get messy otherwise.
What about a "FileExtensions" line? Then we might convert each file
extension to application/x-ext-(file extension), though it will add some
code to the file loader plugin for converting and checking for these mime
types.Something like what the file loader plugin is doing for checking
supertypes in mime types.

Regards,
Arnel