EventSource logs on mono - linux

I am using EventSource to log events in my library. That library is cross platform meaning it could be used by linux/mac users. I know how EventSource works on windows. Users can view default logs using tools like PerfView or Logman tool or implement EventListener class to direct logs to a different location.
But EventListener class is not available on mono. Where are the events logged by EventSource by default on linux/mac? Are there any tools available to view them?
Please let me know if more details are needed.

Just look at source code for EventLog here. There you will see there are 3 event log implementations on mono:
Windows event log (obviously works only on windows)
Local file even log (logs to local file)
Null event log - just drops everything you log.
How it chooses one? It looks at environment variable MONO_EVENTLOG_TYPE. If it's not present, and you are not on windows - null even log is chosen (which should answer your question where your logs will go by default).
If variable is present and equals "local" - it will log to local file. If you want to know where exactly it will put those files, look here. You will see default path for such logs on linux is "/var/lib/mono/eventlog".
All in all - if you develop cross-platform library, consider using something other than pure EventLog (some library like log4net is already fine, and configurable, and can log to EventLog too, among other options). As noted in comments - you indeed can set that environment variable for current process with SetEnvironmentVariable, but still other concerns remain valid.
EDIT: Sorry I was a bit confused and answered quite another question :) Now I see you mean ETW. So ETW is Event Tracing for Windows and I doubt it is implemented in mono. In fact you see yourself with a link you provided in comments that EventSource class is just a stub which does nothing. Mono has quite a lot of such stubs so that your .NET code can compile and run, even if some functionality is not implemented. So answer to your question is - ETW is not supported on mono. You can get around that by checking on which platform do you run in your EventSource implementation, and if you run on mono - don't use WriteEvent but instead log to another place (log4net file as an example).

Related

Why Chrome on Linux shows "External protocol request" dialog for unknown protocol?

I am creating a custom protocol handler for Google Chrome on Linux. My link looks like this:
Trigger my app with param
I have noticed that if 'myprotocol:' is not registered (my app not installed), Google Chrome on Linux displays "External Protocol Request" dialog and tries to use xdg-open:
While on other OS, such as Windows 10 and OS X El Capitan nothing is displayed if protocol is not registered.
I have also verified that Firefox works consistently for unknown protocols on Windows, OS X and Linux - nothing is displayed.
Chrome behavior on Linux is quite confusing for users.
Any idea why Chrome on Linux (I was testing on Ubuntu 14.04) acts differently from any other OS and web browsers?
The issue is really that if Chrome lacks a local protocol handler then it wants to use the handler configured in the user's environment. No two OSes provide exactly the same API to launch a default handler. Figuring out what this program would be before actually launching it is not even a clear API on Windows or Linux.
Both the "Mac" and Windows implementations end up knowing which external application is ultimately responsible for the protocol and therefore are able to suppress unhandled calls without issuing a call warning. But the windows implementation is actually a kludge that relies on observations of the windows registry on existing versions on windows. This type of API violation is more dangerous on Linux where many flavors have very different forks of the related settings tools.
It is actually considered a bug that Windows and OsX don't issue an alternate warning that they've called nothing, so you may want to comment here if you think that is the right behavior.
Here is my observation of how the 3 systems work based on the current source:
Linux
In Linux, when you register protocol handlers with the (window) system, you do something like:
xdg-settings set default-url-scheme-handler myprotocol evolution.desktop
Now, the application evolution is responsible for your protocol and anything can call:
xdg-open myprotocol:...
To now open evolution on these links. The other OSes have similar mechanisms, but may not have an external program as the call stub.
This is nice and abstract and knowing/saying the external app you are calling is xdg-open prevents much complication in the linux implementation. But it is not exactly the information the user probably wants. Getting that information would require using xdg-settings instead and risks being incorrect if there is or ever will be a way to conditionally override the default handler in some flavors of this system.
Windows
In the Windows handler, apparently you can just go snooping around in the registry and then make an educated guess as to what calling the api is going to actually do. Technically, chrome has to do this since the way it opens external programs is through a system API, so there is not an external stub like xdg-open to refer to in the warning.
Mac
In the "mac" handler, there is a proper API to ask about the app your specific URL will launch, so chrome does, then if the application name the empty string it can completely drop the call before generating the warning.

Setting a "hard-coded" flag in sources during build process

I am developing a (Groovy) application that I build via Gradle (on a Continuous Integration server). That application should be compiled into two versions: one development build (including some features I only want to enable for myself), and one public build (which would not include or just disable those "development features").
One solution to this would be to have something like a global flag directly in the main class of the application, something like static final boolean PUBLIC_RELEASE. Then within my code I could check for that flag and enable or disable a certain feature.
Now in my Gradle build script I could check for an environment variable (set by the Continuous Integration server). If that variable is set, then I could set (i.e. change) the current value of the flag to either true or false before the sources are being compiled.
I am sure that approach would work. However, it does not feel right to modify the sources themselves during the build process. On the other hand I would assume this is kind of a standard task for many software projects.
Is there any "best practice" to deal with this requirement?
Is can work out three way for handling the scenario - ordered in the way I would do that:
Create a dedicated properties file the is filtered during build and added to the final jar. Application behavior is determined by this file on runtime. Basically this is how such scenario is handled, but such file can be modified in jar directly by the user.
Source code filtering, hint ReplaceTokens. This seems the best way of securing the application, since the behavior is compiled into code directly, but also problematic when it comes to filtering.
Configure the behavior of application by passing system properties -D at runtime. There's a possibility that a lot of such properties should be passed so it might be problematic for the end user and the configuration of the application is explicitly exposed.

moving from log4cxx to log4net

I have a largish application that currently uses log4cxx as its logging system. However, these appears to be a dead project, and I cannot get it to work with Visual Studio 2013. As such, I am looking to move to log4net
Our project is a mixed C+/C# project, using .net 3.5, and the logging is pretty simple
What is the best way to handle this migration. Any particular problems that people would expect to see, any required changes to config files, etc.
Also, is there a simple tutorial on how to use log4net. Unless I'm misreading it, it appears to be a case of reading the source examples until you figure it out.

Using System.Diagnostics.EventLog in a C# daemon and mono-service

I've just managed to implement my first daemon using C# and mono (hurrah). It's working all fine except one thing. In windows for a service to log into system's log base, one should use System.Diagnostics.EventLog class. This class comes with a method named WriteEntry to log a string into system logs. The same class exists in mono and compiles just fine but it seems it does nothing. Or perhaps I don't know where to look. Where does the logs generated this way go?
It's not 100% clear from your question - are you expecting the event log code to be working on Linux?
If so, perhaps this answer will help you.

Is it possible to intercept dns queries using LSP/SPI?

I wrote my own LSP which is working fine. However, I can not catch dns queries. For example there is no function like WSPGetHostByName or WSPGetAddrInfo.
My lsp also supports UDP protocol but it is not working. If I run nslookup from console (cmd.exe) it seems working but i can not catch gethostbyname. Does anyone know how to do that? I don't think writing NSP (Name Service Provider) is a solution. But I might be wrong.
Thanks
We have developed a LSP that can "intercept" DNS queries. The only way to do it is by hooking into all of the DNS functions, keep in mind there are a few challenges you need to solve:
You need to use a good hooking library that will support both 32bit and 64bit code.
The library license must be right for your application, there are some free libraries, but can be used freely only with free projects.
When you hook the functions, you need to make sure not to modify certain values that are not IP based and defer the query to the real function.
Intercepting UDP will not work since the queries are going out from MS DNS client, so unless you write a low level driver like: TDI, NDIS or WFP you must hook the functions (or write a NSP). NSLookup works for you because it creates the DNS queries itself.
My solution would be as follows:
Take the well known web browser: firefox.exe
copy it into a new name: icefoxy.exe
modify the EXE so it will load a custom DLL.
I have already done this a few months ago, but since Firefox is constantly getting updates, that means:
EITHER: keep one version and do not update (at your own risk, may cause security problems since that means vulnerabilities will not be fixed)
OR: Update your modification every time firefox.exe changes.
The DLL can easily be written using Delphi.
The Firefox modification needs assembly language, unless you know how to download all necessary files to compile firefox yourself, have access to a C/C++ compiler (likely mingw-gcc), and be prepared of the fact that there are 2 mutually exclusive standards of C++, and if your g++ (part of the gcc suite) is incompatible with your Firefox source, then your attempt will fail.
I am not a C++ expert myself, so I took the (for me, at least) easier route using machine language, that way I do not need to be a C/C++ expert to get the job done.
Some relative points:
What functions must be hooked to intercept all Firefox's access to dns server(s) ?
I noticed, that if you load a Delphi DLL into Icefoxy.exe (a renamed copy of Firefox.exe)
then a Delphi form's colors are missing, eg. if you set (either in object ispector or in code):
Label1.Color := clLime;
you still see a label withOUT lime background color. I do not know the exact reason, but it seems that Delphi VCL is relying to be used in an EXE, and when you use Delphi VCL components inside a DLL instead of an EXE, some things (such as color) does not work as intended.
I'd be happy to post my code (both assembly language modifications to Firefox and the Delphi DLL source code) , but how/where can I post it so it is publicly viewable ?
I used Delphi 7 to make the DLL.
if you use Delphi 2009 or later, you need to take extra care that any string data passed between the Delphi code and any non-Delphi code has the correct encoding, due to the fact that In Delphi 2009 and all newer versions, the type String is an alias to unicodestring, where in older Delphi versions, the type String is an alias to AnsiString.
At the time I did this, it was just a small experiment to find out if I can force Firefox to load my own DLL inti it's process address space.
Another interesting idea would be to get access to the DOM (Document Object Model) of Firefox from a Delphi DLL, that would give a working alternative to using TWebBrowser (based on ActiveX version of Microsoft's Internet Explorer).
I know there have been components like TWebBrowser based on Firefox, but their problem is that nobody cared to update them for a very long time, so they are compatible only with some very outdated version of Firefox.

Resources