[PATCH] Add support for GNU/Hurd

[André Hentschel]

Am 03.01.2014 16:49, schrieb Svante Signell:
> Hi,
> 
> On Fri, 2014-01-03 at 15:35 +0100, André Hentschel wrote:
>> Am 03.01.2014 12:32, schrieb Svante Signell:
>>> Hi,
>>>
>>> Currently wine-1.6.1 FTBFS on Debian GNU/Hurd, see
>>> https://buildd.debian.org/status/fetch.php?pkg=wine&arch=hurd-i386&ver=1.6.1-11&stamp=1388629359
>>
>> This winterbreak i looked into this again, too. I was quite suprised
>> that i had no problems with socket credentials, but it might still be a
>> problem in other hurd distros.
> 
> The only credentials needed by wine is SCM_RIGHTS, and that is already
> supported. The problem was with *context functions and TLS. Since they
> are now supported, wine runs :)  

Which *context functions do you mean?

> Just FYI: There is no current Hurd distro except Debian. Arch Hurd
> exists, but is now outdated. Efforts are ongoing however, to re-vitalise
> it. 
> 
>>> Attached is a patch enabling the build:
>>>
>>> - dlls/ntdll/directory.c: Define a character array on the heap of size
>>> 4096 instead of using PATH_MAX, which is not defined for GNU/Hurd. This
>>> approach was used in dlls/ntdll/file.c:server_get_unix_name() where an
>>> array of size 1024 was defined. In case this solution is not OK, a fixed
>>> size array on the stack could be used, or as a last resort adding
>>> #ifndef PATH_MAX; #define PATH_MAX 4096 to that file (not recommended,
>>> at least from a GNU/Hurd aspect).
>>
>> I recently sent a patch for this and failed, problem is that you can't
>> allocate memory inside an APC callback. I think we should address this
>> first before the other issues.
> 
> If not possible to use the heap, then the stack should be used:
> preferably a fixed size array of 4096 bytes (not PATH_MAX).

AJ didn't like that approach back then...

>>> - libs/wine/ldt.c: Add LDT support for GNU/Hurd
>>>
>>> - dlls/ntdll/signal_i386.c: Add i386 signal handling support for
>>> GNU/Hurd
>>
>> The interesting part of these patches were made by Andrew Nguyen some
>> years ago, i already contacted him some days ago to ask how he wants to
>> proceed with this, no response yet.
> 
> Yes I know, they should hopefully have been integrated upstream a long
> time ago.
> 
>>> Applications tested so far (slow to start) include cmd, hostname, clock,
>>> winemine, wineconsole, notepad, wordpad and explorer.
>>
>> These are winelib apps and a bad indicator for functionality. I tried
>> PowerPointViewer here for this reason and it installs and runs.
> 
> I did only try the functions available under .wine/drive_c, and did not
> find any PowerPointViewer application. Is that an M$ application? 

It is, the challange is to run real PE files :)