What on earth are you talking about?
Everything a programmer could want to know regarding Microsoft tools and APIs is documented on MSDN and technet.
What on earth are you talking about?
I work for a company that makes Orphan drugs. Yes, they're ridiculously expensive. The reason is that the number of patients for our drugs number in the couple of thousands globally. Our workforce to run the entire plant, do QA, maintenance, regulatory administration and production processes etc numbers in the several hundreds. Those people need to be paid every month by what a couple thousand people pay for their meds every month.
And that is without taking into account that this entire plant was built for making this drug, which was an investment of hundreds of millions of dollars, with several millions annually for upkeep and maintenance.
I agree that we probably make a decent profit or we wouldn't be doing it.
However, if subsidizing we to stop, we'd just stop making it because with the numbers I mentioned above, it is impossible to make our drugs in a manner that would be affordable without it. And that would mean those people would simply die.
And they paid $12 in taxes.
services.msc is the Microsoft Management Console snap-in for controlling the service control manager. It's really not the thing that's similar to systemd. I think the service control manager (SCM) itself is similar, but it also has an API for control and a couple command line interfaces (dos and powershell). I've actually worked on a project on FreeBSD (closed source) where the concept of an SCM type application always came up. In theory it could have provided a nice consistent interface to our "services" to do things like stop, start, query status, logging, etc. All the boiler plate stuff then looks the same from the outside, instead of being more adhoc. I guess with initd and all the shell scripts, you get a few logging utilities and then shell error codes. Other than that, it's pretty much open season.
Anyone who has written a service for windows knows a few things. First, you always need a way to run it as a normal windows console app or debugging it is a royal pain. Second, you better write it so that it shuts down properly or you'll be getting tons of questions about warnings and errors in the event log. Installing and un-installing can also be painful. I can't be certain how/why, but automating the installation, upgrade, and removal of the service was sometimes problematic if someone logged in and left the SCM control panel running.
Once you have all the kinks ironed out, it's really nice. Admins can start and stop things, install/run your service as different users both domain or local. They can also do things like restrict access to the network, etc. and it's all familiar to them. It does take some cooperation on the developer's part. It is possible to write a service that totally sucks. By sucks, I mean it's buggy and therefore doesn't play nicely with the SCM. Leaves cruft in the registry, and so on.
I had an opportunity to write code on windows (c++ and c#) for about 5-6 years after working exclusively on Linux, FreeBSD, IRIX, HP-UX, and Solaris for about 10 years. I really liked it a lot. I worked on win2k3 and xp, and then win2k8 and win7. I thought win2k8/win7 were both really nice. I was actually blown away about how good the MS IDE and debugger is. The shell still sort of sucks (powershell). I wish someone would write a 'native' shell for windows that was cool. I'd event settle for a dos prompt you can resize like an xterm.
There is no technical reason they should be so expensive, components wise I mean. But the development and QA processes, and regulatory filings, audits, and all the other crap to make it suitable for medical purposes, make it so. That is why a WII balance board costs peanuts, but a medical device with similar functionality costs 10K. If has to be developed according to FDA regulatiosn, there need to be mandatory QA controls in place, software needs to be developed according to medical use standards, there is a regular FDA audit to deal with, liability, studies and validations, etc.
The WII balance board just needs to work. For a while. Non calibrated, non validated, and if it doesn't do what is expected in some cases, you get to call tech support instead of file a million dollar lawsuit.
In meaning, there is a difference. But in reality there isn't. Medical applicances are subject to a lot of regulatory requirements that you cannot skip. If you have something that was not developed and released according to the applicable rules, it simply does not meet the standards and none in the medical field can use it for medical applications. You may think it is annoying or stupid or whatever, but it is law. Those regulations and mandatory QA processes exist to make sure that all bases are covered and that you don't get embarrassing 'oopsies' and people fall dead because you forgot to check for something.
Even today, problems still arise, but the goal is to minimize this as much as possible. And when it goes wrong, lawsuits are files for millions of dollars. Whether the distibutor made any money or not doesn't matter. Your well meaning open source project leader -assuming they somehow fullfilled all legal requirements to releasing something for medical use- would be bankrupted in court, even though he never made a penny.
Because all distributors of medical equipment are liable for the damages in case of malfunction. Doesn't matter if you package it up and distribute for free. Your ass is on the line if something goes wrong. That is why there are expensive certifications, regulations, and oversight watchdogs such as the FDA and FAGG (Europe). If you create an ECG appliance, then you had better hope nothing ever goes wrong, because someone dies due to a malfunction, you're bankrupt. That is why even your development and QA processes are subject to severe regulatory requirements.