Windows, NT Object Manager

Charles wrote:You're welcome, Tonatiúh
Keep in mind that at the end of the video we did talk about a part 3![]()
I hear you, the Singularity folks are doing some of the most innovative OS work in the world (though they'd never agree with that). The possible uses of Singularity, and what's learned from it, will take security and reliability to a new level some day...
Much thanks to the Singularity folks who took an hour out of their schedule to talk to Channel 9.
Glad your questions were answered in the video, Manip!
C
Charles wrote:...of course on Windows I can run applications, right?
amotif wrote:
Any chance Bartok and stand-alone compiled-to-native-code apps will happen on XP/Vista in the next five years. (Gratuitous, feel-good question.)
Charles wrote:You're welcome, Tonatiúh [... ... ...]
Great video !!!
Thanks to Singularity team, there is still some hope for managed code. Even though we have to wait a few years for a true managed -> native compiler.
Thank you all for the info.
AIM48 wrote:NGEN ?
amotif wrote:
Any chance Bartok and stand-alone compiled-to-native-code apps will happen on XP/Vista in the next five years. (Gratuitous, feel-good question.)
Tonatiúh wrote:Wow!!!... Niners like sharing my rants and disappointments with them... From some days a go up to now, I was feeling quite guilty because the way I have engaged in some discussions... Indeed I was pity about my self, looking how my awareness have spoted in front of my eyes the faulty manner I have behaved in my last posts... Furtermore, I have thought that the last "Suspension idea from Minh have been implemented and applied to me"... So I comforted my heart telling to my self: "Well, at least you have not been banned; so you may get a lot of profit reading every one's posts and following those whorthwile links many Niners are so kind to share here"... I know for sure, I shouldn't endure to lost those.
Charles wrote: You're welcome, Tonatiúh [... ... ...]
Thank you Charles
Thank you Singularity Team
Thank you Eagle
Thank you Niners... I beg pardon if any body have been offended by me, specially tou you: Leighsword, mot256 and Cornelius Ellsonpeter
Tonatiúh
orbit86 comes to mind.Cornelius Ellsonpeter wrote:I can't think of any reason why you would be banned. Has anybody been truly banned from this site anyway?
Wow. Great stuff.
Bring on #3!
(dupe)
Cornelius Ellsonpeter wrote:[...] I can't think of any reason why you would be banned. Has anybody been truly banned from this site anyway?
I've never been offended by your posts. Although I have thought about taking out a window or two with a piece of flying furniture.
piersh wrote:very interesting stuff.
i have a question, though: what was the reason for choosing to have a separate GC for each SIP? it would seem to me that in a fully trusted environment like this you could have a single GC for the whole system, integrated with the page manager, would eliminate the need for the exchange heap. memory in one SIP would automatically be 'available' to another process, the consistency of the channel being checked by the verifiable 'handing-off' mechanism you described.
I'm the person on the far right, wearing the dark long-sleeve shirt. Manuel is sitting to the left, then Galen, then Jim.
David Tarditi wrote:I'm the person on the far right, wearing the dark long-sleeve shirt. Manuel is sitting to the left, then Galen, then Jim.
David Tarditi wrote:[...] You might want to use a real-time collector for streaming video and a GC with higher throughput for a compute-intensive application. [...]
Thanks again Charles. Was waiting for this one. Can't wait for #3. Maybe a quaterly installment could be put on the agenda. Maybe you could do a whole show on Transactional Memory locks and invariants, and compare/contrast with traditional lock symantics.
I do have a question. You keep asking "why threads" as if you know of some alternative method. TMK, a process always has at least one thread to get anything done. So if you just use process like old unix systems did (before PThreads), your back to forking
and issues with that. Threads are great from a logic flow perspective, but the locks for shared resources become the issue. This transactional invariant memory deal would seem to really help here. As well as any kind of compile time and/or run time tools
that can help verify correctness of syncronization in our programs.
It would be cool to have a simple SQL server SIP (naturally managed) with all managed types as proof of concept. Layered ontop of the sql api is the TSQL block and another CLR block that would allow any new SQL type language to directly call down to SQL spi
without overhead of the ADO layer - so it would be a peer to the TSQL block. Then you could have a MSH Provider block as another peer. So you could "CD" into any instance of SQL and CD into databases and tables to list and manage table data.
Love it! Cheers.
--
William Stacey [MVP]
scarz wrote:Thanks for doing these interviews guys, I am really enjoying them. As a CS student I haven’t gotten to learn much about where we are going with future OS’s, only where we've been. This work is extremely intriguing and makes me confident I'm in the right field (I mean come on - an OS research project has me excited). I can't wait to see part 3 of the video. My hopes for this project would be to push it as the successor to Vista. Cut the cord with legacy systems once and for all. With the new Intel and AMD virtualization technology coming out we can do some awesome stuff with virtualization, so why not run all our legacy apps (dos, 95, 98, XP, etc.) in a Virtual PC under Singularity. It seems to me that the transitioning from Vista to something as drastic as Singularity would not be as hard as in the past with this kind of technology. Most of the important applications would be rewritten in safe code within a few years, and anything not worth rewriting can just be run under the virtual machine. Anyways I know that’s not the point of the project I just hope people see the value in the system your building. Keep it up guys; I’ll be following your work.
Nice!
I'm curious... would Monad run on this, or would cmdlets cause a problem?
Man, I'd so love to see
my web server running on Singularity
Heck, it'd even be worth Spec#ing the whole thing if I could see that happen.
reinux wrote:Nice!
I'm curious... would Monad run on this, or would cmdlets cause a problem?
staceyw wrote:"no, you would have to rewrite at least the win32 console host.. and the runspace probably too, etc..."
Actually, I would be very suprized if they don't have this working already or at least working in some way for their research purposes.
Thanks for such an interesting video, and kudos to the singularity team for their outstanding effort so far (and their awesome ability to explain their work). Looking forward to part III.
One thing I've been thinking a lot about lately is how useful it might be to have a CPU that understands IL. In other words, a specific CLR version is integrated directly into hardware instead of being a software abstraction.
I'm not sure whether this is even feasible but it seems to me that it would have a number of benefits:
Essentially, unsafe code would be non-existant. This is kind of what you're trying to enforce with singularity but at an even lower level. I can imagine such a CPU being really useful in, for example, mobile phones.
Anyway, just ranting . . . thanks again,
Kent
In the second video, I saw that you are doing message passing over channels and run everything in its own SIP.
I did a lot of programming for µnOS which is an OO OS written in C++ including a GC.
It also uses channels for message passing (without message contracts) just like QNX does.
So if every driver runs in it's own SIP, can I write a SIP by myself sending messages to the NIC SIP
to tell it to send raw ethernet packets to the net?
Or has the TCP/IP SIP exclusive rights to communicate to the NIC SIP?
In µnOS we dicided to compile device drivers to DLLs.
So the network service, which is a seperate process in user mode creates an instance of the device driver object(s)
in its own process space and uses a well-defined interface to access these driver object.
Only the network service has a channel over which the other applications can create and use network connections.
How about modularity and the extension of a certain system service?
Let's say your TCP/IP SIP currently supports IP, ICMP, ARP, TCP and UDP.
How would I extend it to support SCTP as well?
Can I write an extension module (e. g. in form of a C# class) that is loaded by the TCP/IP SIP at startup to support SCTP?
Or do I have to write the extension in form of another SIP?
I also saw that you are doing process creation, channel management and security inside the microkernel.
Did you thaught of implementing a SIP in user mode for doing stuff like that?
E. g. the QNX process manager does some of these things in user mode.
At all, you did a great job with Singularity!
I hope Microsoft stays tuned with it!
pacowski wrote:I thought the exchange heap was very neat, but I was wondering how a particular buffer can be marked to be within the exchange heap. Is there a particular method for marking buffers to be used within a channel? There was a description of the contract that is used to communicate across a channel with specific message formats. I was wondering if in the next video someone could address how the exchange heap and channels interract with two communicating processes. More specifically, is there anything special that needs to be done from a programming stand point or is it all taken care of in the message sending code?
Thank you.
kentcb wrote:Thanks for such an interesting video, and kudos to the singularity team for their outstanding effort so far (and their awesome ability to explain their work). Looking forward to part III.
One thing I've been thinking a lot about lately is how useful it might be to have a CPU that understands IL. In other words, a specific CLR version is integrated directly into hardware instead of being a software abstraction.
I'm not sure whether this is even feasible but it seems to me that it would have a number of benefits:
- Security. The security measures currently enforced by a software layer would instead be enforced at the lowest level - in the CPU itself.
- Performance. I'm no expert in hardware but I imagine that performance could be greatly improved (not that it's bad now).
Essentially, unsafe code would be non-existant. This is kind of what you're trying to enforce with singularity but at an even lower level. I can imagine such a CPU being really useful in, for example, mobile phones.
Anyway, just ranting . . . thanks again,
Kent
It is often said that c# is more type-safe than c++.
Does the type-safety is provided by the c# to msil conversion or the msil to x86 conversion.
Because if it is the msil to x86 conversion you can ensure the typesafety of c++ code that have been converted to msil.
To write high performance code in java you should write a librairi in C++ and call it from java and when c++ is not enough you write assembler in your c++ code.
This is because the java Jit-compiler dont optimize as much as c++ compiler, also when doinng ahead of time compiling.
you said you where using assembler in c# code.
So my question is, does the bartok ahead of time msil compiler do as much optimization as c++ compiler.
So i understand that you choose c# over c++ because it is a more high-level language giving more simpler code to read.
But you said that writing a device driver in visual basic can cause some problem because of is dynamic feature.
What do you mean .. (Bartok compiler can't convert msil code produced by VisualBasic to x86) or (the type-safety is hard to ensure in dynamic feature)
Is it possible to create a Ruby to msil compiler that keep the dynamic feature of ruby and can be converted to native x86 code like you do for c#.
This way you would have a highly object-oriented dynamic type-safe language