Building an OS out of an application [closed] - c#

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
EDIT - I'm sorry that I made this post more complicated than it should. I won't delete this post in case someone with a similar question needs help.
I recently became interested in building my own Linux distro(probably just for family and friends). I have researched extensively on whether I should customize an existing distro(eg. Arch Linux, Debian) or build from scratch(LFS). I have come to the conclusion that building from scratch would best fit my needs(Im on no time constraint).
My main question is:
Would it be possible to build an application that functions as a full OS, and just program the linux distro to run it at launch?
Second main question:
Would doing this way restrict programs from being installed? Would developers have to make a custom version of their software to run on this mock OS?
Problems I see in this:
-If I use a language like c#, would that work? or does it require windows natives?
-If I use java(probably not), but if I would, would I have to package JRE with the distro?
-If I use something like java, can I use libraries like LWJGL(for openGL for stuff like window frames)
-Does java or c# use special file system methods? Would I need to make the Linux base build the file system for the VM language to use? Or can I arrange all that in the mock Os itself?
-Performance problems with VM languages?
-Are there any legal problems with packaging things like JRE or if I find a way to use windows natives?
Additional notes:
-I have no concern on time, even if just the file system takes me 3 years.
-If building this from scratch would not be possible, would I be able to customize a distro in order to function like this?
-I understand that I would have to make linux handle stuff like hardware drivers, because communicating with hardware is not something in my ballpark. Would this mean that I have to customize something like Arch Linux?
I am very sorry there are so many questions in this, and if I had enough reputation to add a 500 rep bounty I would.

An operating system is really a huge undertaking. There have been attempts to build a system to create custom OSs in C# called Cosmos, which I've considered looking into several times. In most cases though, applications probably would have to be specifically built for the OS. I may actually bother, now that you've reminded me.
Obviously, the result would not be Linux, but rather a custom OS built using Cosmos. That's probably the closest you can manage using C#.
So in summary: If your goal is to execute managed code on a machine at the most basic level, Cosmos is probably what you want. You will still be doing almost everything, but you'll have some insulation from the actual guts of the machine.
EDIT: Alternatives include Mosa, which does not use Visual Studio, and Singularity, which you can only use for research, but was produced by Microsoft directly.

The short answer is add this to your kernel command line:
init=/path/to/my/application
Typically the first process a Linux kernel will start is the init process. init takes care of running the startup scripts for everything else that needs to start at boot-time - e.g. kernel modules, daemons, console login/x desktop.
You can tell the kernel to use any userspace binary you like instead of the default of /sbin/init, as above, though you may still want some of the startup script to run.
Though more likely, you'll want to edit the startup scripts to just run one application (Is your application text or X-based?)
Alternatively you could hack the kernel to run your application in kernel space, and possibly never even start any processes. But that would be a nightmare to debug/maintain.

Related

My c# TCP Sockets program is being quarantined by Windows Defender [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
I have written a c# program to monitor what my daughter is doing on her computer during her online lessons (due to COVID lockdown).
She has a habit of going onto Discord to chat with her friends instead of following the lesson. She also plays Minecraft during lesson time.
I don’t have the time to keep checking up on her so my wife urged me to write this software.
But the software is detected by Windows Defender as a Trojan as shown below;
Detected: Trojan:Script/Wacatac.B!ml
This program is dangerous and executes commands from an attacker
I can see that it is a Trojan of sorts but it is not being used in that vein. I am simply using TCP SOCKETS to allow myself or my wife to keep an eye on our daughter and to message her and if need be to close down the offending application remotely.
The way that MS Defender keeps quarantining each new compilation as I fine tune the exe to do what I need it to do is a real bind.
I am hoping that somebody might know a way around this.
After all I am using an API (System.Net.Sockets) that is part of the Microsoft DotNet library.
It is as if Microsoft were banning the use of an API that it provides.
My daughter is back at school on the 8th March 2021 so it will be redundant after that (hopefully) but as a developer I would still like to know how to solve this.
... close down the offending application remotely.
To some extent, this indeed makes your program "execute commands from an attacker." It seems like the issue does not lie in whatever API you use - but instead, what the program actually does.
You may try obfuscating your program with something like ConfuserEx, though it is possible that Windows Defender flags the obfuscated build as well, because this is what some real malwares do to hide themselves. The easiest solution is to place the program in a separate directory and add that directory to Windows Defender's exclude list.
We run up against this kind of problem frequently, and realistically there's not a lot you can do about it. False positives are just a part of what we have to deal with, and the only way to deal with them for low-distribution items like personal remote administration tools - or my own common case, custom AV upgrade scripts - is to add exceptions for your own programs when you install them on a computer, and every time you update the code.
It is as if Microsoft were banning the use of an API that it provides.
Unfortunately malware uses those same APIs. AV vendors are constantly upgrading their definitions to catch as many threats as possible and common techniques used by malware are also present in remote administration tools.
From a quick search it looks like Wacatac.B!ml is a particularly problematic detection that has struck all sorts of legitimate applications, including an open-source launcher for Blender recently and several other items.
From experience the !ml tag means that the definition was derived via machine learning which means it most likely is a deep heuristic rather than a code fingerprint.
Possible Solutions
The most general way to get around this type of heuristic detection is with extended validation code signing. Since this requires a relatively expensive certification process it's unlikely to be a useful solution for your in-house child monitoring tools.
In your case perhaps a path or file exclusion would allow you to continue to refine your tool without having to worry about it constantly being detected and blocked. I wouldn't recommend this for production systems, but for home use only it's simple, althout occasionally unreliable.
Finally, you could radically change the code. If you can't find a way to avoid detection using your current code base then consider using a different technique altogether. Enable powershell remoting and run a collector script on another machine on the network. Build a web-based agent that polls a web service (on the local network of course) to get commands to run. Use a popular library that will handle the actual communications for you rather than accessing the sockets yourself. Not as efficient maybe, but sometimes all it takes is one change to get the false positives to leave you the hell alone.

What are the different ways to create two very similar software packages in C# [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am writing a software suite which is essentially composed of two separate applications in C# .Net using WPF. Although they may look a little bit different they essentially work like a lite version and a full version of the same software package. The full version contains all of the functionality of the lite version.
I had previously done this by creating two separate applications which share a class library where all the common user controls go. But i am now wondering if there is any better design for this kind of architecture.
I was even thinking of creating one application and at runtime let it decide which version it was going to work as.
Could anyone with any experience with this type of problem please point me in the right direction.
Keep it Simple
My rule of thumb is whenever possible keep solution as simple as possible. That being said I would use the same composition you are using.
Usually break up projects like this:
Application Logic: CompanyPrefix.ProjectPrefix.Core, CompanyPrefix.ProjectPrefix.Data...etc.
Applications : CompanyPrefix.ProjectPrefix.ApplicationType.App, so some examples :
CompanyPrefix.ProjectPrefix.Web.App
CompanyPrefix.ProjectPrefix.Console.App
CompanyPrefix.ProjectPrefix.Wcf.App
Since you have two Wcf Apps might want to do something like
CompanyPrefix.ProjectPrefix.Wcf.Lite.App
CompanyPrefix.ProjectPrefix.Wcf.App
So in this example both CompanyPrefix.ProjectPrefix.Wcf.App and CompanyPrefix.ProjectPrefix.Wcf.Lite.App point back to CompanyPrefix.ProjectPrefix.Core or wherever your business logic is.
About Dynamically Loading Assemblies
There is a way to dynamically load your libraries at runtime, but unless you're dealing with a modularized system of independent components would recommend against it.
If your heart is set on it there are a lot of resources on MSDN, would probably start here. Article about loading assembly into current application domain.
Come Up with a Checklist
One thing I find helpful is to come up with a checklist to help me make decisions in case I ever get stuck. Usually ends up being something like:
Does this have business value?
Does this make debugging harder?
What are the Pros and Cons of doing it a new way versus the way I have done this in the past?
This isn't my exhaustive list but explains the point. This can really help too when you have a group of people that are largely sticking with choices for personal reasons that don't have any grounding, as well as a tool to use when you get stuck to make a decision and go with it
Dealing with Application Logic Changing (Write Clean Code)
Coming up with an over-complicated "never need to recompile entire application again" is a mistake I have made in the past. You're still going to need to deploy and compile something.
Most important thing about dealing with changes in application is to
Have Code on Source Control (most important)
Write Clean Code
Write Tests
Write Documentation ( I know no one likes to do this )
Write some more Tests
What will consume most of your time when dealing with application changes is debugging so focus on reducing the amount of time you spend debugging not a amount of time you spend compiling and deploying
For Deployment setup Continuous Integration
If you have the ability to setting up CI would eliminate 99% of the hassle of changing the application. You lose a day or two setting things up for the first time, but it is well worth it.
Check out TeamCity and Travis CI

Why should I create setup project [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
When I am creating projects in VS I only add a set up project to my solution if it is a service (I can't get it running without installing it first).
If the prorgam isn't a service I don't normally create a set up project but rather copy the .exe file as well as all the necessary dlls for the application to run to a desired folder and I run the application from there.
My question is if there is any benefit in terms of performance or anything else when you install a program (through its set up) rather than just running it without having it first installed it
It highly depends on needs of your application. You may for instance:
Add necessary registry entries
Register file extensions to your application
Check prerequisites and (potentially) install missing libraries or frameworks
Check for potential problems, which will disallow your application to work correctly
Allow user to choose only subset of features your application offers (thus making the installation smaller)
Choose binary and library files for specific environment (for example 32 vs 64-bit). For example, NVidia now gives you one unified installer for a series of graphics cards and then installer chooses the appropriate ones to install.
Automatically add shortcuts to start menu/screen and desktop
You can of course embed most of these actions in your application, but I'd vote against that. That's because your application would have some boilerplate code, which would run only once, or even your application might not start because of missing requirements, which setup application might have resolved.
Also, it's less user friendly. With setup program, users may very quickly prepare application to work and also - equally quickly - remove the program from their computer (along with all config files, registry entries etc.).
If you plan to use the program only by yourself, it's your choice. But if you want to publish your program, I'd suggest at least making an option to either install program or use it in the portable mode (without installation).
I think there are benefits of having setup project from end-user and developer perspective as well. Normally when you finish your project you want to easily distribute it. End users are rather used to downloading and installing application in a common way meaning:
selecting the destination path
select whether to install for all or only current user
checking whether to create desktop/programs menu icons or not
lunch the program after installation
and this can be easily accomplished by setup project.
I think regular user finds hard to let's say
download compressed file
extract package (assuming that appropriate for doing it is already
installed. In other case it is required to install it)
create dektop shortcut

Creating a scripting environment for a C# program [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Say I have an application that is connected to a database, with its own forms that present data and allow data to be changed & entered, how would one extend the program to be extensible by a third party?
For example a third party would be able to write scripts that the user can run that would prompt the user for input. Part of the script would then take what the user inputed (integer/string/boolean) and do some basic programmatic things to it, math on integer values, concatenation on string values (and other string functions), and logical tests to trigger further user prompts etc etc, the scripting environment would also support reading/writing to the application's database.
Would this be done simply by having text files the program could run, with each line corresponding to a certain command? Then the application would read each line, figure out what command the line represents, and equate that to C# code? Are there any already existing solutions to this problem?
The question is fairly open, here some proven great extension tools:
Compiled Plugins written in C# would use Managed Extensibility Framework (MEF), a great and well designed extensibility option.
Scripted Extensions in C# might be possible soon when Roselyn is ready.
Scripting could also be accomplished by integrating Jurassic into your application.
There are several good choices if you want to embed a scripting language into a c# app. IronPython, IronScheme and IronRuby alL support the Dynamic Language Runtime so they can access objects from the host code. There's also Boo, which is a strongly typed CLR language that looks a lot like Python but can be easily embedded in a C# application and, like to the others, can interact with the host application. In general the embedding process is pretty simple - Michael Foord's IronPython site has a good example.
There's also NLua which is supposed to be a CLR friendly lua wrapper, but I have no personal knowledge of that one.
Out of all of the above, I'd expect the main thing driving your choice will be the preferences of the user base. Especially for the lightweight application you've described all of these choices should be well suited. If you wanted users to be able to do extensive programming on their own it's more complex, since the CLR ports of these languages dont usually support the same binary extensions as their C-based counterparts - for example, IronPython can't use the regular Perforce API module because it is built on a C-based binary extension module. All Iron* languages can use the same base class library as C#, though - you can import System.Windows.Forms into any of them to create GUI and so on.

Is Mono stable and fast enough? [duplicate]

This question already has answers here:
Is Mono ready for prime time? [closed]
(17 answers)
Closed 8 years ago.
C# looks great because it is a compiled language which seems to run quite well without too much CPU and does not consume too much memory. And StackOverflow and ServerFault are good examples of an MVC/.Net/C# stack that scales.
C# is also interesting because despite being compiled, it still has a lot of advanced features as a language only found on slower interpreted language.
My server being Linux only (Ubuntu 8.04 LTS), I am wondering if installing Mono in place of the .Net framework is a good idea for production use.
I currently do not have any existing applications using .Net but I am interested in using existing frameworks (like MS MVC).
Stable enough and fast enough to do what?
It will have different levels of stability and performance depending on what you want to do, I'm sure. For example, one of my Protocol Buffers unit tests (which uses Rhino.Mocks) manages to make the Mono VM abort with an assertion error - but I have no idea (currently) of whether that would affect anything else I'm doing, or whether it's just related to the form of proxying being used.
I suggest you try it and see.
ASP.Net MVC is now open source. That it is now integrated into MonoDevelop via an add in would suggest that you are likely to get things working.
Given the very new status of this you should expect issues. This blog should be a reasonable starting point for you.
Remember that many ASP.Net MVC tutorials assume you have a sql server back end, this is unlikely to be feasible (given your question) so bear that in mind.
You'll have to judge it on a feature basis. At my current customer we're running a high-volume document processing and delivery system written in .NET 3.5. We have a Linux server that runs Mono with .NET components that take care of the delivery of documents to the outside world, e.g. through FTP. That runs fine in production.
We did run into a problem with the Mono implementation of the .NET FTP component, which forced us to look for other third party .NET components, which solved the problem. So you might run into things like these. But in our case: once we got it to work, it worked just fine and stable.
I think that Mono is REALLY stable and complete.
It brings .NET to *nix World.
In my company I'm leading a project aimed to build an automated machine. This machine is built by different devices that need to be governed using a serial interface (RS232).
The machine exposes a touch screen for user interaction.
One of my responsibilities is to project the logic of the system beyond the GUI application.
I've chose Mono (used for presentation layer) also to build a custom middleware that runs the application business logic.
This middleware is some sort of application server and it's executed in Ubuntu 10.04 LTS.
For now all the system is an advanced prototype, but also the final product will keep its heart in the couple Linux/Mono.
I hope that these considerations could be useful for you.
Regards,
Giacomo
as i had read on mono project wait for MONO 3.0 it will solve the main problem in mono means memory leakages and garbage collectors so before 3.0 we can't say it as stable but it is a life line for developers like us who want to develop platform independent s/w with dot net.

Categories

Resources