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

Chromium11 #7

Closed
wants to merge 17 commits into from
Closed

Chromium11 #7

wants to merge 17 commits into from

Conversation

romainpi
Copy link

OK, big pull request. Feel free to use any part of it. Sorry about the excessive number of commits linked to it, I'm not the most skilled Git user.

Most notable changes are:

  • Custom URI scheme, using code from K.Gadd taken at: http://code.google.com/p/berkelium-sharp/
  • All exes and libs should now be built in the bin/ folder (except demo binaries), this reduces silly mistakes.
  • ScriptVariant now uses a real boolean to hold the bool value. There was a bug with the old implementation.

Please note:

  • This has all been done on Windows. I hope I haven't broken Linux or Mac... Sorry if I did...
  • This work is part of work I've been doing to update BerkeliumSharp, which I will post soon, somewhere.

@romainpi
Copy link
Author

Also, I'll try and update the samples to use the new features.

@romainpi romainpi closed this Oct 27, 2011
@romainpi romainpi reopened this Oct 27, 2011
@pathorn
Copy link
Member

pathorn commented Oct 30, 2011

Hey, thanks for implementing the protocol handlers. I'll see if I can get around to this in the next few days.

I'm going to have to take a look at the HGLOBAL...that's going to cause problems because it's windows-specific. Is there any reason to use a HGLOBAL instead of a simple char*/length?

I think what I am going to do is have the handler implement a function "freeMemory" or something which takes a char*, or a "freeLastRequest" function so that you can allocate the memory, return it, and then free it later.

Too bad we can't use std::string across DLL boundaries--Microsoft messed that one up thanks to all the incompatible VC++ runtimes out there :(

@kg
Copy link

kg commented Oct 31, 2011

The HGLOBAL thing is because it has to be safe to allocate and free across DLL boundaries. It probably makes sense to add a custom solution to this to the Berkelium API. I used HGLOBAL in BerkeliumSharp since it was already windows-only.

P.S. romainpi, thanks for salvaging this stuff! Wish I had the time to do so myself :)

* Added a build event for Berkelium: it will now automatically copy all the runtime DLLs it needs from Chromium.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants