When using libxml API, the lib will automatically allocate some memory.
How can I change the default memory allocator/deallocator for libxml?
Is there any API for this purpose?
Thanks.
Yes, there's an API. Have a look at the functions provided by the xmlmemory module, especially xmlMemSetup:
int xmlMemSetup (xmlFreeFunc freeFunc,
xmlMallocFunc mallocFunc,
xmlReallocFunc reallocFunc,
xmlStrdupFunc strdupFunc)
Override the default memory access functions with a new set. This has to be called before any other libxml routines!
Related
I am trying to disable CORS in TEdgeBrowser and found a lot of solutions by using ICoreWebView2EnvironmentOptions because TEdgeBrowser is implement by WebView2.
In Microsoft's document, the sample code seems to used for Visual C++ and C++ Builder is not applicable:
auto options = Microsoft::WRL::Make<CoreWebView2ExperimentalEnvironmentOptions>();
Here is the code I have tried in C++ Builder 11:
_di_ICoreWebView2EnvironmentOptions *m_WV2_EnvOpt = new _di_ICoreWebView2EnvironmentOptions();
m_WV2EnvOpt->put_AdditionalBrowserArguments(L"--disable-web-security");
It would fail in m_WV2EnvOpt->put_AdditionalBrowserArguments().
I have no idea and maybe I got the wrong way. Can someone help me?
_di_ICoreWebView2EnvironmentOptions is a typedef for DelphiInterface holding a ICoreWebView2EnvironmentOptions* pointer. You don't use new on DelphiInterface itself, you new a class that implements the interface, eg:
class TCoreWebView2EnvironmentOptionsImpl : public ICoreWebView2EnvironmentOptions
{
// implement IUnknown and ICoreWebView2EnvironmentOptions as needed...
};
_di_ICoreWebView2EnvironmentOptions m_WV2_EnvOpt = new TCoreWebView2EnvironmentOptionsImpl;
However, WRL objects are not used this way.
In this case, the WebView2 library exposes ICoreWebView2EnvironmentOptions as a COM object, so you can use CoCreateInstance() to instantiate it (the CLSID for the WebView2 library is 26D34152-879F-4065-BEA2-3DAA2CFADFB8, and the IID for ICoreWebView2EnvironmentOptions is 2FDE08A8-1E9A-4766-8C05-95A9CEB9D1C5), eg:
_di_ICoreWebView2EnvironmentOptions m_WV2_EnvOpt;
CoCreateInstance(LIBID_WebView2, NULL, CLSCTX_INPROC_SERVER, IID_ICoreWebView2EnvironmentOptions, (LPVOID*)&m_WV2_EnvOpt);
However, that doesn't help you in this situation, because you would have to provide the created ICoreWebView2EnvironmentOptions object when creating the WebView2 object, and AFAIK TEdgeBrowser simply does not allow you to do that.
You could try setting the WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS environment variable before the WebView2 object is created, but AFAIK this method does not support the --disable-web-security option.
What's the best way to open a file in the default application from Vala?
A bit like how xdg-open works.
I found some existing code in another application, but later on I also found this
GLib.AppInfo.launch_default_for_uri method.
A simple example:
var file = File.new_for_path (file_path);
if (file.query_exists ()) {
try {
AppInfo.launch_default_for_uri (file.get_uri (), null);
} catch (Error e) {
warning ("Unable to launch %s", file_path);
}
}
If you're using GTK, then you've also got Gtk.gtk_show_uri_on_window(), which uses the GLib stuff under the hood.
As far as I know there is only one implementation of the relevant freedesktop.org standards.
That is the reference implementation in xdg-utils:
https://www.freedesktop.org/wiki/Software/xdg-utils/
The tools are written in shell script, for example here is the source code for xdg-open:
https://cgit.freedesktop.org/xdg/xdg-utils/tree/scripts/xdg-open.in
So by far the easiest way is to just call the xdg-open script via Process.spawn_async and friends.
If you insist on using a library function you would have to implement a standard conforming library yourself.
Update:
There are quite a few libraries in various languages that implement some of the freedesktop.org standards, for example here is a list on GitHub:
https://github.com/topics/xdg
For example here is a similar tool to xdg-open written in D:
https://github.com/FreeSlave/mimeapps/blob/master/source/mimeapps.d
What I didn't find so far is a Vala / GLib or plain C library that could easily be used from a Vala application.
Update 2:
Actually it turns out there is something for that purpose in GLib (or more precisely in Gio):
https://valadoc.org/gio-2.0/GLib.AppInfo.launch_default_for_uri_async.html
https://developer.gnome.org/gio/stable/GAppInfo.html
So you should be able to use the GLib.AppInfo.launch_default_for_uri_async method.
I want my application to always run using the real gpu on nVidia Optimus laptops.
From "Enabling High Performance Graphics Rendering on Optimus Systems", (http://developer.download.nvidia.com/devzone/devcenter/gamegraphics/files/OptimusRenderingPolicies.pdf):
Global Variable NvOptimusEnablement (new in Driver Release 302)
Starting with the Release 302 drivers, application developers can
direct the Optimus driver at runtime to use the High Performance
Graphics to render any application–even those applications for which
there is no existing application profile. They can do this by
exporting a global variable named NvOptimusEnablement. The Optimus
driver looks for the existence and value of the export. Only the LSB
of the DWORD matters at this time. A value of 0x00000001 indicates
that rendering should be performed using High Performance Graphics. A
value of 0x00000000 indicates that this method should be ignored.
Example Usage:
extern "C" { _declspec(dllexport) DWORD NvOptimusEnablement = 0x00000001; }
The problem is that I want to do this using Delphi. From what I've read Delphi does not support export of variables even though some hacks exists. I did try a few of them but couldn't make it work.
In the same nvidia document I read that forcing the proper GPU can be accomplished via linking statically to one of a handful listed dlls. But I don't want to link to dlls I'm not using. (Why the opengl.dll is not one of them is beyond me.) A simple exported variable seems much cleaner.
From what I've read Delphi does not support export of variables.
That statement is incorrect. Here's the simplest example that shows how to export a global variable from a Delphi DLL:
library GlobalVarExport;
uses
Windows;
var
NvOptimusEnablement: DWORD;
exports
NvOptimusEnablement;
begin
NvOptimusEnablement := 1;
end.
I think your problem is that you wrote it like this:
library GlobalVarExport;
uses
Windows;
var
NvOptimusEnablement: DWORD=1;
exports
NvOptimusEnablement;
begin
end.
And that fails to compile with this error:
E2276 Identifier 'NvOptimusEnablement' cannot be exported
I don't understand why the compiler doesn't like the second version. It's probably a bug. But the workaround in the first version is just fine.
I'm not a Delphi expert, but AFAIK it is possible to link to static libraries implemented in C from Delphi. So I'd simply create a small stub library, just providing this export, which is statically linked into your Delphi program. This adds the very export you need.
I want do exactly this:
embed DLL into EXE
but without using of resources (the DLL binary should not be visible in resource viewer but stay hidden inside of the executable code).
I tried to convert the file into string literal(s) but the file is too big and I only get out of memory or stack overflow exceptions when trying to compile it:
const cFileSize = 2424564;
const cFileBlock =
'30820274020100300D06092A864886F70D010101'+
'05000482025E3082025A02010002818100D713B2'+
...
'BF1F8167F517D3945C27CABCB1E7D7C4092336B9';
What do you suggest:
a)try some means to meet compiler memory limitations (like split to more include files etc.)?
b)convert the DLL to object file and link it with the application (which tool?)
c)some other way?
Thank you
I can confirm that solution proposed in the comments above works:
const cFileBlock: array[0..2424564-1] of byte = ($30, $82, ..., $B9);
The compiler does not complain about stack overflows and out of memory errors anymore.
But I will not use this solution anyway because of possible false threat warnings from antivirus software, see the comments above again.
Thank you all for help.
Why not just use a CRC checksum ?
If your goal is to ensure that the DLL has not been tampered with in any way, you can store a CRC in your program which is calculated from a known untampered DLL. Then later, simply read in the DLL and compare the calculated checksum of that DLL with what you have stored.
One thing to watch out for is if the person/company that produces the DLL makes a change, then a different checksum will result and this updated checksum will need to be stored in your application or else the program will "believe" the DLL has been tampered with if the updated version is used.
I'm trying to update from OpenCV2.4.10 to OpenCV3.0.0. OpenCV provides a basic guide for how general APIs work after the update, however, it doesn't cover how to deal with some implementation and API changes that have been removed completely. Is there a definitive guide to this process?
For example, one specific problem I'm encountering is that a library I'm using calls a function that has been removed from OpenCV3:
static CV_IMPLEMENT_QSORT( icvSortDistances, int, CV_LT )
How can I replace CV_IMPLEMENT_QSORT? It appears to be originally defined in cxtypes according to this blog post. There is another similar function of note CV_DECLARE_QSORT, which may also not be in 3.0?
Also several components use the opencv legacy libraries, are there any known or suggested upgrade paths for those?
How about replacing it with :
static void icvSortDistances(int *array, size_t total, int )
{
std::sort(&array[0], &array[total]);
}