Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get Servo working on Windows #1908

Closed
kmcallister opened this issue Mar 13, 2014 · 58 comments
Closed

Get Servo working on Windows #1908

kmcallister opened this issue Mar 13, 2014 · 58 comments

Comments

@kmcallister
Copy link
Contributor

@kmcallister kmcallister commented Mar 13, 2014

Stuff we need to implement for sure:

  • Build system (Rust uses MinGW/MSYS; we can do the same)
  • Font loading
  • Sending OpenGL textures between GL contexts and (eventually) between processes

And then there's probably a lot of other work we don't know about.

See src/platform/ and src/support/layers/rust-layers/platform/.

Rust already works but some of the things we use may be missing.

We will never, ever support Windows XP.

@Ms2ger

This comment has been minimized.

Copy link
Contributor

@Ms2ger Ms2ger commented Jun 5, 2014

Windows might not be so happy about the 80 -L arguments we pass to rustc.

@Manishearth

This comment has been minimized.

Copy link
Member

@Manishearth Manishearth commented Feb 10, 2015

Going to use this as a tracking issue

@Manishearth

This comment has been minimized.

Copy link
Member

@Manishearth Manishearth commented Feb 10, 2015

Status

Native bindings:

Bindings that need to be written:

  • Something for font loading, à la Fontconfig/CoreText (#4901)

OpenGL stuff: I don't know what the status on this is.

Build system: Since Rust only supports MinGW, we'll stick to that.

  • mach is not cygpath friendly

CI: To be looked into later. Much later. Appveyor may work for deps but it's hard getting the env set u

Other blockers:

In the longer term we'd need to add VS support to Rust, which mainly consists of getting librustc_back to support other linkers.

@Manishearth

This comment has been minimized.

Copy link
Member

@Manishearth Manishearth commented Feb 10, 2015

@Manishearth

This comment has been minimized.

Copy link
Member

@Manishearth Manishearth commented Feb 10, 2015

Makefile notes (servo/rust-harfbuzz#36, servo/mozjs#27):

Check for Windows (ifeq (windows,$(findstring windows,$(TARGET)))), then do the following:

  • OUT_DIR:=$(shell cygpath "$(OUT_DIR)")
  • ifeq (cc,$(CC)), set CC = gcc, CPP = gcc -E
@retep998

This comment has been minimized.

Copy link

@retep998 retep998 commented Feb 10, 2015

On Windows we can abandon OpenSSL and use WinHTTP which is a native system library. It is what Cargo uses on Windows. But since MSYS2 can provide us with an OpenSSL package, it isn't too much of a hassle.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa382925%28v=vs.85%29.aspx
As for font loading, use the native Windows methods?
https://msdn.microsoft.com/en-us/library/dd162620%28v=vs.85%29.aspx
https://msdn.microsoft.com/en-us/library/dd183499%28v=vs.85%29.aspx

@Manishearth

This comment has been minimized.

Copy link
Member

@Manishearth Manishearth commented Feb 10, 2015

We'd need to make Hyper and Servo SSL-backend-agnostic then, which sounds like more work.

Besides, the handling of cookies depends on libcrypto. If we get openssl on msys2 that should be enough, otherwise it's not too hard to just build it (we do this for Android already)

Native windows methods sound good. Even better if we can wrap it in an API that's like fontconfig or something.

@tomaka

This comment has been minimized.

Copy link

@tomaka tomaka commented Feb 10, 2015

Glutin (should just work)

The Windows implementation of glutin is actually the one that I trust the most. I think you can check this box.

@abonander

This comment has been minimized.

Copy link

@abonander abonander commented Feb 11, 2015

I would like to volunteer fontconfig-rs for cross-platform font location. It doesn't technically have OS X or Windows support yet but it's really just a matter of having it pass a custom config to fontconfig that tells it where the fonts live on those platforms, though fontconfig itself would have to be built for Windows. GIMP is already doing it.

I'm considering having fontconfig-rs pull in the source for fontconfig and build it on Windows platforms so the user doesn't have to bother fetching it.

@retep998 Has winapi-rs touched those font APIs yet?

@retep998

This comment has been minimized.

Copy link

@retep998 retep998 commented Feb 11, 2015

@cybergeek94 No but I can easily add any methods needed.

@vvuk

This comment has been minimized.

Copy link
Contributor

@vvuk vvuk commented Feb 11, 2015

For fontconfig, is what's needed just font selection, which is then passed to Skia for shaping and rasterization? Win32 fontconfig already exists as part of the win32 gtk+ port as was mentioned above, so it may be possible to just use that along with fontconfig-rs. Bundling all these DLLs (openssl, fontconfig, etc.) together in a "servo-win32-support" package would probably be helpful so that people don't have to download everything individually.

I can help with the GL texture sharing cross context/process stuff.

@metajack

This comment has been minimized.

Copy link
Contributor

@metajack metajack commented Feb 11, 2015

Won't not using platform font enumeration methods result in users seeing inconsistent fonts between native platform apps and Servo? Or is fontconfig using native facilities behind the scenes?

@vvuk

This comment has been minimized.

Copy link
Contributor

@vvuk vvuk commented Feb 11, 2015

It will; I would expect that along with stuff like openssl, it would be a stopgap measure in order to get a port up. Then pieces can be rewritten to use the native Windows APIs,or at least to work in a more Windows-like manner. On Windows, Gecko uses DirectWrite natively, though font selection is mostly done by Gecko directly and less by fc. (Fc gets used for enumeration/querying/etc.)

@abonander

This comment has been minimized.

Copy link

@abonander abonander commented Feb 12, 2015

@metajack Windows stores all its fonts in pretty much one location (C:\Windows\Fonts), so there shouldn't be any discrepancy between the selection queried through the Win API and fontconfig. It just makes for a nice cross-platform abstraction so Servo's design doesn't get bogged down in one platform's API.

While the Unix-based platforms actually have a bit more fragmentation in this area, OS X is really the only complex platform for font location since it has a few different directories that need to be configured, while on Linux, fontconfig is installed through the given package manager for a distro with a configuration file that tells it where the fonts live in that particular distro.

@retep998

This comment has been minimized.

Copy link

@retep998 retep998 commented Feb 12, 2015

Not all fonts on Windows are actually stored in C:\Windows\Fonts. Fonts can be added and removed at any time using AddFontResource, where they will be listed in the fonts when you use the Windows API for enumerating fonts, but they won't actually be in the Fonts folder. A WM_FONTCHANGE will be sent to all top level windows to indicate of any such additions/removals as well.

One of my biggest gripes with GTK software is that it doesn't detect fonts added or removed while the program is running, something that Firefox does very well. So if GTK is what uses fontconfig, then I don't want fontconfig.

@abonander

This comment has been minimized.

Copy link

@abonander abonander commented Feb 12, 2015

@retep998 I wouldn't depend on those fonts being available for any respectable amount of time if they can be added and removed at will. I don't think Servo should, either. FWICT, installed custom fonts are copied into this folder so they are available at any time, which would be my only concern if they weren't.

@retep998

This comment has been minimized.

Copy link

@retep998 retep998 commented Feb 12, 2015

Fonts can be added or removed from the Fonts folder at will as well, and we'd need to hook into the notifications regardless to detect that. If we want to be robust, we have to take the approach Firefox uses. If we don't want to be robust for now, just to get things working, that's fine. But eventually this is something that we'll need to do.

@Manishearth

This comment has been minimized.

Copy link
Member

@Manishearth Manishearth commented Feb 12, 2015

What does Firefox do here?

@Manishearth

This comment has been minimized.

Copy link
Member

@Manishearth Manishearth commented Feb 12, 2015

07:40 < nattokirai> gecko builds lists of font families on the system
07:40 < nattokirai> then fills in the details as needed
07:41 < Manishearth> nattokirai: any library we can use?
07:41 < nattokirai> for windows there are two backends, one using DirectWrite, the other GDI API's
...
07:42 < nattokirai> um, "library" meaning modular piece of code that can simply be imported into servo? no... :P
07:42 < Manishearth> dammit
07:42 < nattokirai> but...
07:42 < nattokirai> the directwrite API is fairly sane
...
07:43 < nattokirai> look through the code in gfx/thebes
07:43 < nattokirai> look through the code in gfx/thebes

I guess we should have a look at DirectWrite?

@nattokirai

This comment has been minimized.

Copy link

@nattokirai nattokirai commented Feb 12, 2015

Not sure what servo is doing for CSS font matching but that code really needs to exist in servo, since you need an implementation for on-demand loading for @font-face families. You really want to use native platform API's and not fontconfig for this. So DirectWrite on Windows, CoreText on OSX, fontconfig on Linux and roll-your-own on Android.

@abonander

This comment has been minimized.

Copy link

@abonander abonander commented Feb 12, 2015

Sounds like a new library project: cross-platform font querying using native APIs.

@nattokirai

This comment has been minimized.

Copy link

@nattokirai nattokirai commented Feb 12, 2015

Yeah, the level of support for various things related to fonts needed by a modern web browser varies across platforms. In general, you'll need to maintain some sort of font lookup interface and fill in what's needed on a per-platform basis. OSX and DirectWrite are fairly easy, fontconfig and Android are relatively painful. Gecko uses platform API's to maintain a list of font families available and fills in data for a given family when it's actually used. Font style matching really needs to be done by servo code and not punted to platform-level API's which have their own rules for style matching.

@nattokirai

This comment has been minimized.

Copy link

@nattokirai nattokirai commented Feb 12, 2015

Key features of a font system interface:

  • lookup a font family name
  • enumerate styles within a single family
  • select a given face within a family based on CSS font properties (i.e. weight/width/slant)
  • activate a font from data (with required sanitation such as OTS)
  • lookup individual font faces via a fullname or Postscript name
@nattokirai

This comment has been minimized.

Copy link

@nattokirai nattokirai commented Feb 12, 2015

For browsers you'll also need:

  • system font fallback, the ability to find a font for a given character
  • mappings of generics based on language/script (e.g. sans-serif for Arabic and Japanese are not the same font)
  • ability to read (and cache) font metrics and font table data
@khouzam

This comment has been minimized.

Copy link

@khouzam khouzam commented Mar 9, 2015

Thanks for reaching out.

The instructions to build OpenSSL are pretty straightforward. You can look at the latest on https://github.com/openssl/openssl/blob/master/INSTALL.W32

It does require Perl and supports Visual C++, Borland and GCC.

In 3 steps for Visual Studio it would be:

  1. git clone https://github.com/openssl/openssl.git
  2. perl Configure VC-WIN32 no-asm --prefix=c:/some/openssl/dir
  3. ms\do_ms

From a VC++ prompt
4. nmake -f ms\ntdll.mak

And you should have the DLL version of OpenSSL built and available.

@ghost

This comment has been minimized.

Copy link

@ghost ghost commented Mar 10, 2015

That's it! Thank you! 👍

@Manishearth

This comment has been minimized.

Copy link
Member

@Manishearth Manishearth commented Jun 12, 2015

I fixed up the png compile.

servo/rust-png#73

@Manishearth

This comment has been minimized.

Copy link
Member

@Manishearth Manishearth commented Jun 12, 2015

A relatively simple task that can be done here is making mach cygpath friendly when it sets the PATH environment variable amongst other things.

@Manishearth

This comment has been minimized.

Copy link
Member

@Manishearth Manishearth commented Jun 12, 2015

Fixed up stb too

servo/rust-stb-image#71

@Manishearth

This comment has been minimized.

Copy link
Member

@Manishearth Manishearth commented Jun 12, 2015

Skia seems to need MSVC to build on windows

There are some instructions for getting it to work on mingw, but they seem dated:

https://groups.google.com/forum/#!topic/skia-discuss/LO1kdT0tmNs

https://code.google.com/p/skia/issues/detail?id=213

@waddlesplash

This comment has been minimized.

Copy link

@waddlesplash waddlesplash commented Jun 12, 2015

Does Rust use a new enough LLVM that the MSVC ABI can be used? That would solve the problem without requiring MinGW.

@Manishearth

This comment has been minimized.

Copy link
Member

@Manishearth Manishearth commented Jun 12, 2015

rust-lang/rust#25350

Rust can build on MSVC, it's just new. And while most things will just work with mingw, the same is not true for msvc.

@Manishearth

This comment has been minimized.

Copy link
Member

@Manishearth Manishearth commented Jun 12, 2015

OpenSSL seemed to magically build for me on mingw64. I'm ticking it off, but it's possible that this was just my setup.

@indivisible

This comment has been minimized.

Copy link

@indivisible indivisible commented Jun 14, 2015

I've tried to cross-compile servo on a Linux host to Windows. What I did:

  • set up a simple mingw environment (I used https://github.com/lachs0r/mingw-w64-cmake)
  • clone servo
  • clone the rust version it needs, build it with windows support, and put it somewhere the build process will find
  • try to build servo

I got a bunch of bugs with some cargo packages, which I've reported and worked around myself.
For some of the problem packages (fontconfig, openssl) I just hacked the build to link the glue code to libraries I built with the mingw env's packages.
The major problem I got stuck at is that the Skia changes for Servo are NOT ported to Windows yet (only OS X, Linux and Android are supported.)

The cross-compile process is mildly painful, but not impossible. (Although I have some pretty strong words for whoever keeps inventing new build systems at Mozilla.)

@vvuk

This comment has been minimized.

Copy link
Contributor

@vvuk vvuk commented Aug 13, 2015

Can you shove your hacks and changes in a gist? I'd like to work from there. I can definitely port the Skia changes over etc., but need to get through the random cargo etc. breakage with fontconfig/openssl/etc.

@vvuk

This comment has been minimized.

Copy link
Contributor

@vvuk vvuk commented Aug 13, 2015

Note that I think that it's acceptable to have an initial Servo-on-Windows have dependencies such as: requires msys2/mingw64 build env; requires clang-cl (or real msvc) to build some modules; etc. We can then remove them over time but at least we have something that can be hacked on.

@pcwalton

This comment has been minimized.

Copy link
Contributor

@pcwalton pcwalton commented Aug 13, 2015

Note that we'll need some kind of ipc-channel port now.

@vvuk

This comment has been minimized.

Copy link
Contributor

@vvuk vvuk commented Aug 13, 2015

Writing the code is the super easy part of all this. I will happily write code all day long. It's fighting with build system cruft that's the painful bit..

@waddlesplash

This comment has been minimized.

Copy link

@waddlesplash waddlesplash commented Aug 13, 2015

Note that we'll need some kind of ipc-channel port now.

Windows' named pipes? They aren't very secure (if you know the name of the pipe, you can read stuff off of it, essentially) but they're tried, true, and fast.

@jasonwilliams

This comment has been minimized.

Copy link
Contributor

@jasonwilliams jasonwilliams commented Sep 7, 2015

is there any low-hanging-fruit i can help with?

@Manishearth

This comment has been minimized.

Copy link
Member

@Manishearth Manishearth commented Sep 7, 2015

Not that I know of, though @vvuk might have some tasks he can delegate

@retep998

This comment has been minimized.

Copy link

@retep998 retep998 commented Sep 8, 2015

Someone can always go write a Rust library around DirectWrite, especially since there are raw bindings to it.

@vvuk

This comment has been minimized.

Copy link
Contributor

@vvuk vvuk commented Sep 8, 2015

My current plan is to get things compiling, stubbing out as necessary along
the way even if the final result doesn't work. Then it will be much easier
to parallelize getting things to work, since people won't be fighting the
build the entire time. I hope to have things compiling in the next day or
two, then a day of submitting PRs and replicating the work from scratch.
On Sep 7, 2015 5:08 PM, "Manish Goregaokar" notifications@github.com
wrote:

Not that I know of, though @vvuk https://github.com/vvuk might have
some tasks he can delegate


Reply to this email directly or view it on GitHub
#1908 (comment).

@waddlesplash

This comment has been minimized.

Copy link

@waddlesplash waddlesplash commented Sep 8, 2015

Someone can always go write a Rust library around DirectWrite, especially since there are raw bindings to it.

FWIW, I really do not like the way Chrome (at least) looks with DirectWrite turned on. Maybe that's Chrome's fault and not DirectWrite, but I prefer Firefox's font rendering on Windows by a lot. Ubuntu's default font rendering settings surpass it by a lot, though.

@retep998

This comment has been minimized.

Copy link

@retep998 retep998 commented Sep 8, 2015

Maybe that's Chrome's fault and not DirectWrite, but I prefer Firefox's font rendering on Windows by a lot.

Firefox also uses DirectWrite on Windows. There's a ton of tweaking you can do to adjust how text is rendered.

frewsxcv added a commit to frewsxcv/servo that referenced this issue Sep 8, 2015
This will eventually need to be done for servo#1908
bors-servo pushed a commit that referenced this issue Sep 9, 2015
Use OS-agnostic filesystem paths in Python

This will eventually need to be done for #1908

<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7568)
<!-- Reviewable:end -->
josiahdaniels added a commit to josiahdaniels/servo that referenced this issue Sep 28, 2015
This will eventually need to be done for servo#1908
@waddlesplash

This comment has been minimized.

Copy link

@waddlesplash waddlesplash commented Oct 6, 2015

@larsbergstrom

This comment has been minimized.

Copy link
Contributor

@larsbergstrom larsbergstrom commented Jan 27, 2016

Landed in #9385!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.