> So, I would definitively rather hire a developer who has written a few
*well working* drivers
on NT/XP/Vista, because in my experience that generally proves that he
knows *more than a
little bit* about kernel APIs and kernel insides - than a developer, who
might have twice as much
solid experience on some other OS kernel architecture and driver
programming.
I can see through this sentiment and do not disagree but would like to also
respectfully add that a lot of chips of more complex nature ( as someone
pointed out ) already have existing stacks that interact with not just one
OS but
several OSes and as they go forward they deal with hardware and
architectural issues not necessarily
OS issues. IMO a more flexible person who has an indepth understanding
would be more
useful than a fly by night driver writer who might not have gone through the
rigours of OS/ comp arch.
I m sure every company including the company that provides the OS under
question here has
research going on that is not necessarily academic but aimed at the next
generation. Same goes for chip
companies too. I m sure you ll not be surprised as a phD yourself as to the
nature of futuristic ideas/algorithms
that get put into production and kick Ass.
thanks
banks
“Sandor LUKACS” wrote in message
news:xxxxx@ntdev…
> bank kus wrote:
>> Thank you so much 
>>
>> All this in answer to the following question so I dont get taken wrong:
>> “who would you hire especially in a fast moving chip company”, someone
>> that knows a lil bit about some kernel API having written a few drivers
>> or a thorough OS/ comp arch expert that understands the whys and not
>> necessarily the hows of a particular OS and has a good understanding
>> of software engineering. I m not trying to answer this question:)
>>
> I was asking many times similar questions. Let me however share with you a
> personal opinion
> or experience if you wish (and also I would like to ask the more
> experienced people around
> there to comment on this opinion, if possible).
>
> I am currently working on FS minifilters. Prior to this I had done 2K/XP
> file system dev.
> And those two jobs / tasks are BY FAR the hardest from everything I have
> done till now.
> The biggest issue here I think is to understand the inside working of a
> quite big and complex
> OS as NT/XP/Vista is. It is A LOT easier to build something quite
> independent from the
> scratch than to build something that MUST use a lot of existing APIs,
> depend on and
> work reliably with existing OS components.
>
> (Just for comparison, what I have done before: several years of OOP like
> programming
> both of UIs and quite complex multi-threaded and distributed software
> architectures, including
> lots of multi-threaded synchronizations, including design and architecture
> of commercial
> software solutions and small team management. I have build from ZERO two
> research /
> academic level operating system kernels and minimal API, including SMP
> programming on
> x86 and x64, IPC primitives, mult-threading synchronization from the
> scratch, some graphical
> video card programming, two zero level sound card programmings, DMA ATA
> programming,
> some zero level realtek network card programming, multiple consoles, a
> fully functional
> assembler, partially working (non optimizing) C compiler for x64 and so
> on. I have had taught
> for several years assembly language, OS architecture and recently basics
> of NT architecture
> and driver programming for faculty students. I’m also currently working on
> my PhD in the
> field of OS architecture, especially OS reliability.
> All those are, and where EASIER to accomplish than NT/XP/Vista FS driver
> programming.
> And I really think, this is generally true for several other NT driver
> types also…)
>
> So, I would definitively rather hire a developer who has written a few
> well working drivers
> on NT/XP/Vista, because in my experience that generally proves that he
> knows more than a
> little bit about kernel APIs and kernel insides - than a developer, who
> might have twice as much
> solid experience on some other OS kernel architecture and driver
> programming.
>
> (As about research in let say more esoteric OS topics, different languages
> and kernel
> architectures, they do have some great results. But until those results
> get down to solid and
> widely usable commercial stuff I think they are ‘academic’ and
> ‘experimental’ (no offence).
> Of course it is possible, that in ~10 years time drivers and OS core will
> be no more in C,
> but in some other language, maybe different paradigms, different
> multi-threading approach
> and so on.)
>
> have a nice day,
>
> Sandor LUKACS
> Virus Analyst, SOFTWIN
>
>> As a --sidenote–, parallel programming doesnt start with pNp management
>> in some driver code. There is volumes of research that takes place on
>> parallel programming including special languages that are tailored for
>> them. But I guess end of day it is an individuals choice:
>> “would you want to sit and code using pthread in a monotonous language
>> like C” or “research how to better split an incoming serial algorithm at
>> runtime into a parallel algorithm”. For the former 30 years of experience
>> will do you wonders.
>>
>> banks
>>
>
>
>