While not related specifically to Windows system software, this happens to be a topioc that’s Microsoft OS-related that I’m personally interested in, so I thought I’d share.
The Singularity Research Development Kit (RDK) from Microsoft Research was made available yesterday for download by anybody who’s willing to agree to the non-commercial Research License Agreement.
The source-code and license agreement are available on CodePlex: http:
Peter
OSR</http:>
Appreciate it so very much, Peter …
-pro
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Wednesday, March 05, 2008 7:07 AM
Subject: [ntdev] OT: Singularity OS Kit Now Generally Available
> While not related specifically to Windows system software, this happens to
> be a topioc that’s Microsoft OS-related that I’m personally interested in,
> so I thought I’d share.
>
> The Singularity Research Development Kit (RDK) from Microsoft Research was
> made available yesterday for download by anybody who’s willing to agree to
> the non-commercial Research License Agreement.
>
> The source-code and license agreement are available on CodePlex:
> http:
>
> Peter
> OSR
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer</http:>
Thanks, Peter
Anton Bassov
Stupid question. Is anybody other than me having issues getting this
thing to unpack?
By the way, thanks, Peter.
mm
xxxxx@osr.com wrote:
While not related specifically to Windows system software, this happens to be a topioc that’s Microsoft OS-related that I’m personally interested in, so I thought I’d share.
The Singularity Research Development Kit (RDK) from Microsoft Research was made available yesterday for download by anybody who’s willing to agree to the non-commercial Research License Agreement.
The source-code and license agreement are available on CodePlex: http:
>
> Peter
> OSR
>
></http:>
I did not have any prob. unpacking it. Must be some config issues on Ur
side.
I’m even using 64bit vista, and unzip went fine …
-pro
----- Original Message -----
From: “Martin O’Brien”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Wednesday, March 05, 2008 2:39 PM
Subject: Re:[ntdev] OT: Singularity OS Kit Now Generally Available
> Stupid question. Is anybody other than me having issues getting this
> thing to unpack?
>
>
> By the way, thanks, Peter.
>
> mm
>
>
> xxxxx@osr.com wrote:
>> While not related specifically to Windows system software, this happens
>> to be a topioc that’s Microsoft OS-related that I’m personally interested
>> in, so I thought I’d share.
>>
>> The Singularity Research Development Kit (RDK) from Microsoft Research
>> was made available yesterday for download by anybody who’s willing to
>> agree to the non-commercial Research License Agreement.
>>
>> The source-code and license agreement are available on CodePlex:
>> http:
>>
>> Peter
>> OSR
>>
>>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer</http:>
wrote in message news:xxxxx@ntdev…
> Thanks, Peter
>
> Anton Bassov
Will you now start a “c++ vs. c# in kernel” discussion? 
P.
Sure why not :).
We will have some statical electricity due to charged discussion, and
friction with collision, but I don’t think it’s gona go beyond 20 volts :).
And we probably have enough Ohm to digest it to lower Amps
-pro
----- Original Message -----
From: “Pavel A.”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Wednesday, March 05, 2008 2:42 PM
Subject: Re:[ntdev] OT: Singularity OS Kit Now Generally Available
> wrote in message news:xxxxx@ntdev…
>> Thanks, Peter
>>
>> Anton Bassov
>
> Will you now start a “c++ vs. c# in kernel” discussion?
>
> P.
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
> Will you now start a “c++ vs. c# in kernel” discussion?
Nope. IMHO, they are both inappropriate in kernel under the *existing* OS model. However, I am not yet in a position to voice my opinion about Singularity due to the lack of any, because, AFAIK, it uses totally different approach to everything, so that popular concepts, probably, don’t apply to it (BTW, it is written not in C# but in Spect#, which is, apparently, “the same but still different” language). Therefore, I have nothing to say here. However, even if I had, it would not qualify for thread hijacking in any possible way - after all, as it follows from the title, this thread is meant to be off-topic issue from the very beginning…
Anton Bassov
My opinion of how very cosmically badly C++ sucks is, by now, legendary. However, I am a fan of C# – which came to me as quite a surprise, given that I initially thought it was just some useless proprietary Microsoft massaging of C++… which it most decidedly is not. Well, not entirely.
There’s no reason whatsoever that I can see why *at some point* C# (or managed code in general) could not be used in kernel-mode in Windows. Yeah, sure… there are “issues” with things like the CLR and GC. But, there are PLENTY of smart people who can solve these things. I don’t see anything that rules out using C# in the Windows kernel a priori.
Can you imagine? Load-time determination of whether you get the free or checked build of your driver code? No more bad pointers? Sign me UP!
And, how about using C# for (the ever increasing pool of) drivers that are written in user mode? Sounds like a win to me…
Peter
OSR
> There’s no reason whatsoever that I can see why *at some point* C#
(or managed code in general) could not be used in kernel-mode in Windows.
I believe a better option is just to move as many components as possible out of the kernel, in the first place. Once the target component gets moved to the UM… well, at this point various options become available - as long as it does not execute ISRs and DPCs, it can afford some “inefficiency”, so that, probably, writing it in a managed language may be an option. However, I think that writing code that is not allowed to block (i.e. ISR and DPCs) in any language, other than C or asm, is an awfully bad idea…
Anton Bassov
xxxxx@hotmail.com wrote:
[…] as long as it does not execute ISRs and DPCs, it can afford
some “inefficiency”, so that, probably, writing it in a managed
language may be an option.
…and don’t forget we need a good reason to buy the next hardware
generation with more and faster processor cores. 
(In the embedded world some people actually use 8-bit cores to handle
time-critical tasks. It is an old (reliable) architecture with no
interrupt latency. The new 32/64-bit architectures with multiprocessing
OSes running on them don’t cut it for some of their purposes.)
> (In the embedded world some people actually use 8-bit cores to handle time-critical tasks.
It is an old (reliable) architecture with no interrupt latency. The new 32/64-bit architectures
with multiprocessing OSes running on them don’t cut it for some of their purposes.)
I am afraid you are comparing oranges and apples. These CPUs and OSes that run them do not have to be generally either too fast or too intelligent - the only thing they have to do is to handle very limited set of tasks that are known in advance. However, 32/64-bit architectures
and multiprocessing OSes running on them have to handle a variety of tasks that are not known in advance. They have to be generally fast and intelligent, but still they are not required to handle some specific task as fast as RTOS that is optimized specifically for a given task would. It just does not make sense to even compare these two - they serve totally different purposes…
Anton Bassov
> (In the embedded world some people actually use 8-bit cores to handle
I have heard that now the manufacturing cost of 32bit ARM is lesser then of old
8bit core.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> I have heard that now the manufacturing cost of 32bit ARM is lesser then of old 8bit core.
Never mind 32-bit ARM - it seems to be almost in the past. Intel now introduces Atom Processors, which, according to them, in terms of functionality and instruction set, is the same thing as your desktop’s Core2… but a die the size of 1 US cent can contain up to a dozen cores, so that it is meant to be used in hand-held devices. It sounds incredible, but it looks like now hand-held devices are capable of running 64-bit OSes (they say that a device with Atom processor should be capable of running Vista, so that it must, apparently, have a couple G of RAM)…
Anton Bassov
Maxim S. Shatskih schrieb:
I have heard that now the manufacturing cost of 32bit ARM is lesser then of old
8bit core.
These people buy the 8051 core as IP and then integrate it (or several
of them) into their own chip design. And with its low gate count it’s
certainly relatively cheap to add to a design.
xxxxx@hotmail.com schrieb:
I am afraid you are comparing oranges and apples. These CPUs and OSes
that run them do not have to be generally either too fast or too
intelligent - the only thing they have to do is to handle very
limited set of tasks that are known in advance.
However, 32/64-bit architectures and multiprocessing OSes running
on them have to handle a variety of tasks that are not known in
advance. They have to be generally fast and intelligent, but still
they are not required to handle some specific task as fast as RTOS
that is optimized specifically for a given task would. It just does
not make sense to even compare these two - they serve totally
different purposes…
This was exactly my point - as came out in another discussion, we can
have a modern multicore 3GHz 64-bit CPU that has an interrupt
latency which is easily beaten by any ancient 8-bit processor.
Same for time-critical bit-banging (or byte-banging) I/O.
IMHO we now are in the same position like the “big iron” designers -
the CPU is extremely powerful, but if you need something done in a
guaranteed timeframe you better go for a special periperal control
processor. Which does not need to be very fast or complex.
Why would that sound incredible, when you consider that my cell phone has
more processing power, more RAM, and more storage than ALL the computers
that supported the Lunar landings, and the two Voyager missions combined.
–
The personal opinion of
Gary G. Little
wrote in message news:xxxxx@ntdev…
>> I have heard that now the manufacturing cost of 32bit ARM is lesser then
>> of old 8bit core.
>
> Never mind 32-bit ARM - it seems to be almost in the past. Intel now
> introduces Atom Processors, which, according to them, in terms of
> functionality and instruction set, is the same thing as your desktop’s
> Core2… but a die the size of 1 US cent can contain up to a dozen
> cores, so that it is meant to be used in hand-held devices. It sounds
> incredible, but it looks like now hand-held devices are capable of running
> 64-bit OSes (they say that a device with Atom processor should be capable
> of running Vista, so that it must, apparently, have a couple G of RAM)…
>
>
> Anton Bassov
>
Gary G. Little wrote:
Why would that sound incredible, when you consider that my cell phone has
more processing power, more RAM, and more storage than ALL the computers
that supported the Lunar landings, and the two Voyager missions combined.
Yes, indeed. I sometimes consider the first Cyber 73 mainframe I worked
on in 1976. It filled a 400 square foot room, required a dedicated
staff, a complete custom power grid (for 400 Hz power), and plumbing for
chilled water; it cost $5 million, and had 64k words of memory and a 10
MHz clock. My watch has much more compute power than that.
And yet, we used to timeshare 45 users routinely.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Continuing to veer OT but Gary has astutely pointed out (perhaps indirectly)
one of the most serious problems in our industry:
The success of the Apollo program, Voyager program, and all of the
*incredible* achievements of that era were possible not just because of the
(now almost silly amount of) computing power available on board the craft
but because of the enormous amount of preparation, design, review, quality
assurance, scenario testing, and *good old fashion engineering* that went
into the project before the ‘fuse was lit’ (so to speak). As a more
present day JPL learned, no amount of computing power can engage the breaks
on a space probe when the R&D process fails to catch a simple error in
design (Mars Lander makes ‘hard’ landing).
The idea that these engineers and scientist could predict and prepare
relatively simple system to continue to function some 4+ decades later,
having taken into account such things as bit-rate reduction as function of
distance, Doppler shifting in carrier frequency, power budget, antenna
aiming based on stellar positioning, etc. etc. etc. when we have trouble
sometimes thinking beyond the next release is sobering. When one probe
lived so long and traveled so far that even NASA was surprised, I recall
reading an article about how the mission team figured out how to reprogram
the onboard controller from way back here on earth with a few extra memory
cells that had been put in place ‘just in case’ and viola’ the mission was
extended. No that is a hotfix!
By any measure of our industry observable to the consumer, we are drunk on
letting Moore’s law and consumer apathy replace good, solid engineering
practices.
Sure there faster. So what? Are they *better*?
I am far more impressed by my vintage HP29c’s ability to store and execute a
200 instruction sequence mathematical simulation of the “Lunar Lander” 30
years into its life then I am with my incomprehensibly annoying cell phone
and its multiple processors (whatever they are). Imagine where Voyager
would have been if the engineers who designed it had an HP calculator
instead of a slide-rule.
Wow? Did I write that? Time to put me in the same pile as the Z80 assembly
language books.
-dave
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Thursday, March 13, 2008 1:33 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] OT: Singularity OS Kit Now Generally Available
Why would that sound incredible, when you consider that my cell phone has
more processing power, more RAM, and more storage than ALL the computers
that supported the Lunar landings, and the two Voyager missions combined.
–
The personal opinion of
Gary G. Little
I thought that was incredibly intelligent and cogently written. You should edit it and submit it to run on the op-ed page of The New York Times or IEEE Spectrum or something.
Well done,
Peter
OSR