|
I am so glad I write in C still. I can remain blissfully ignorant of all this latest must have technology.
Imagine the time spent learning COM, all wasted. Java too, gone by the wayside.
Good old C, it lasts forever! 
|
|
|
|
|
Me thinks C++ try you should. I never looked back.
... such stuff as dreams are made on
|
|
|
|
|
I use C++ in MFC for writing test apps and the odd cpl applet, but so much of what I do is process based that C really is the best language.
|
|
|
|
|
C IS good, indeed... Maybe C++ a bit better... But there are lines of development you can not use them... Not without spitting blood at least...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Of course, fortunately I dont go anywhere near those lines of development!
|
|
|
|
|
Lucky you! 
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Benefits of working in the kernel, it hasnt really changed in decades, seriously.
|
|
|
|
|
Very lucky indeed. Always wanted a chance to work in this area. But, very rare opportunities.
In the other hand, I wonder if you ever get bored of doing the same kind of job again and again. I do...
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
Linux is in demand, Windows less so, but when a firm does need that skill it is hard to find someone to do it, so it pays well.
However, bored? Never, each problem is so distinct that it is never dull. For me the work is the project, not the environment, and they are ever changing and sometimes very complex.
|
|
|
|
|
Munchies_Matt wrote: it is hard to find someone to do it
If only finding someone "willing" to do it was enough. It's hard to develop experience on this. To me it feels like the chicken/egg problem at this stage in my career.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
It is a bit like that.
Problem is most hardware for windows is US designed, so the drivers are written there, though more and more are being done in places like India (usually badly in my experience) and Taiwan.
MSFT has tried to make it easier with the WDF model, which is a lot easier to use, much of the hard work is done for you, but unless you go into the WDM foundation of the kernel you wont understand just how complex it is. And it is mind bendingly complex.
I got a lucky break, a UK defence firm wanted a driver for one of their ISA bus network cards for NT4, so I dug into the DDK and taught myself how to do it. It was a tough learning curve, but NDIS is a simple model, so it was a good start really. I did a serial driver for the same firm later on, it had an unusual protocol, so the off the shelf one wouldnt work.
After that it took about 5 years of writing windows drivers before I really became competent. It takes that long.
Now, 20 years later, I know it pretty much inside out, though you can always be surprised by the subtlety of the API, and the MSFT documentation is not always that good.
And with that I have done some pretty weird and wonderful drivers, like one to control CPU speed, so an app can run flat out, but at low CPU speed, for processing at night. Or the current one I am working on, bridging USB, so it takes USB traffic in and sends it out to some FW that then mimics that device to another PC at the far end. Very very fiddly, because all the USB config data has to be passed on, as well as a route back from the far end whcih actually does the configuration, and the class and vendor requests.
And it has to support up to 8 devices...
It is a seriously complex architecture, I really hope I dont have to maintain in in 5 years, I will have no idea how it works!
|
|
|
|
|
Thanks for the insight. I once started experimenting kernel mode driver development. I wanted make this Zebra printer receive commands via USB (it only received via serial port). Since I didn't have much time I ended up giving it up while I was digging and learning how complex it was.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
I have known a few people have a try for a few months, then give up. It really takes years and years to get an idea of how it works.
|
|
|
|
|
Poem - Write in C 
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
|
|
It adds a lot of cruft. Complicates server deployment.
Or at least: that is how it feels.
... such stuff as dreams are made on
|
|
|
|
|
More complicated. But can be automated...
You may be interested in my article about .NET Core (the second one)...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
I was thinking in terms of updating .NET itself, when there are dependencies between all the applications and the core. Maybe you cover that too, but I saw no link
Köszi
... such stuff as dreams are made on
|
|
|
|
|
It does not cover .NET Core updates, as I do not consider it as a developer problem.
It is about hosting the very same compilation on different platforms... ASP.NET Core: compile once, host everywhere[^]
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: It is about hosting the very same compilation on different platforms
Errr....as with java the actual idiom would be 'code once' and then 'test everywhere'.
|
|
|
|
|
I have been doing server development for at least 20 years. Implementing Rest layers (and before that Soap, http and TCP) on down to the database. And designed all it as well.
Exactly what sort of servers are you writing where the architecture and requirements themselves are not the principal source of the complexity?
There was only one time where language choice was objectively justified and that was based on business/marketing/finance requirements rather than any technological need.
|
|
|
|
|
3. Does not write .NET apps but uses [insert your favorite language] for cross platform applications
For me, it is C++ with cross platform frameworks like Qt and C, C++, and Perl for console applications.
|
|
|
|
|
It is actually 2. - you consider your current cross platform solution better (or good enough)...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
I think it would be a good choice if I would write .NET apps (and have not used many methods that are not supported by .NET core).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
: