Hi,
Since I graduate this year, this may be the last time I participate--or at least, attempt to participate, since last year didn't quite work out for me :(--in Summer of Code. (I realize I was supposed to email you last week, but what's done is done.) So, without further ado, here's what I'm proposing:
1) Make Wine use App Sandbox on Mac OS X.
A project that used to be listed on the SoC ideas page was to implement proper sandboxing in Wine. Apparently, you think this is unrealistic, because you took it down. (Not the page, just that suggestion.) But, I think that if I narrowed my focus a bit, it could be possible to do this. I'm proposing using the Mac OS App Sandbox API--the beginnings of which were introduced in 10.5 and which came into its own in 10.7--to improve security of Wine on Mac OS. Wine is an excellent candidate for the App Sandbox, because most of its file-system activity is limited to a single directory--namely, the Wine prefix. I'm not sure what you think of this, though, so I'm throwing this out there to get feedback. At the very least, I would like to be able to limit Wine's file-system activity to the prefix.
2) HLSL compiler.
Well, my D3D bytecode backend to LLVM didn't pan out like I'd hoped. Maybe an LLVM-based compiler is too complex for Wine right now. But perhaps we don't need it right now anyway. If CodeWeavers can't afford to pay me, maybe Google can. I can add a simple parser and compiler (that performs little or no optimization) that hopefully would be sufficient for Wine's purposes.
3) Integrate pieces of DCE/RPC into Wine.
As you may or may not know, in Mac OS 10.7, Apple stopped using Samba (probably because it uses the GPL3 as its license) in favor of their own implementation--which just so happens to be based on the original DCE/RPC implementation (the same one that was used as a base for MS RPC). I figured we could cannibalize pieces of it for our own use. Or is that not acceptable?
What do you think? I'm not sure how useful or feasible these are, so I'm posting to the list before.
Chip
Am Mittwoch, 28. März 2012, 22:10:27 schrieb Charles Davis:
- HLSL compiler.
My general response to "HLSL Compiler" would be "too complex for gsoc, too much work, nope", but since I know that you worked on compilers in the past it might work for you. I cannot promise anything of course, but my guess is that it is worth writing an application.
I think three things would be important:
1) A plan how to integrate the compiler step by step. I think a general consensus is to start with a parser that can parse the entire (d3d9?) language, but I don't know what the idea is beyond that.
2) A flexible plan that allows for adjustments depending on how the project progresses, once a complete parser is done.
The good thing about the parser is that I've once written a hacky compiler as a school project, and the parser is pretty much complete for d3d9 shaders. Even if the other code is pretty ugly, the parser should be reusable.
3) A design that is flexible enough for future needs(or well, d3d10/11). I am still afraid of getting stuck in a dead end street with anything written from scratch, but since all other options failed I guess that's the only way left.
Maybe Henri and Matteo can weight in with their opinions as well.
Cheers, Stefan
-
Charles Davis -
Stefan Dösinger