Windows NT/2000/XP services ?

The following article says "DCOM uses an implementation of distributed
computing environment (DCE) RPC." It does not say anything about use of UDP.
If DCOM uses UDP then that would sure be worth knowing about; is there
another article that describes use of UDP by DCOM?

Building COM Components on UNIX
[url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvc60/html/msdn_unixcom.asp[/url]


"Arkady Frenkel" <arkadyf@hotmailxdotxcom> wrote in message
news:ua7iH%23b2DHA.3496@TK2MSFTNGP11.phx.gbl...[color=blue]
> DCOM use UDP with known ( defined ) message format ( the first bytes are
> MEOW word ( a cat was near MS guys when they thought about format :)[/color]
IMHO ).

The layering is:
DCOM over RPC over <some rpc transport>
some RPC transports suitable for DCOM (some have been discontinued along the
way)
are ncacn_ip_tcp, ncacn_np, ncalrpc, ncadg_ip_udp
The "network" protocol for the tcp family is DCE with the appropriate
payload
in the PDU_REQUEST/RESPONSE (after the presentiation context and transfer
syntax
have been negotiated the DCE way).

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
[url]http://www.microsoft.com/info/cpyright.htm[/url]


"Sam Hobbs" <samuel*socal.rr.com> wrote in message
news:uuQ4ive2DHA.2620@TK2MSFTNGP09.phx.gbl...[color=blue]
> The following article says "DCOM uses an implementation of distributed
> computing environment (DCE) RPC." It does not say anything about use of[/color]
UDP.[color=blue]
> If DCOM uses UDP then that would sure be worth knowing about; is there
> another article that describes use of UDP by DCOM?
>
> Building COM Components on UNIX
>[/color]
[url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvc60/html/msdn_unixcom.asp[/url][color=blue]
>
>
> "Arkady Frenkel" <arkadyf@hotmailxdotxcom> wrote in message
> news:ua7iH%23b2DHA.3496@TK2MSFTNGP11.phx.gbl...[color=green]
> > DCOM use UDP with known ( defined ) message format ( the first bytes are
> > MEOW word ( a cat was near MS guys when they thought about format :)[/color]
> IMHO ).
>
>[/color]

On Tue, 13 Jan 2004 07:19:57 -0800, "Sam Hobbs" <samuel*socal.rr.com>
wrote:

<snip>
[color=blue]
>
>Yes, a DOS TSR is very primitive, just as DOS is primitive. DOS TSRs are a
>bad example but the important thing is to make it clear that "First we had
>components... and now services." is the result of a huge misunderstanding.
>Unless I misunderstand what is meant by "components", the valididty of that
>statement is so far from the truth that it must be corrected.[/color]

Agreed

I don't see DOS as totally primitavely as some do. DOS (Be it the Disk
Access System, or MS-DOS or any flavor of the sort) are solid, proven
methods of navigating. Even the 'nix clients use a command prompt.

Now, before anyone goes up rear about my ignorance, or whatever, GUI of any
flavour is definately superior in the mannor of being able to display
information in a more pleasing way, but, I can't count how many times I've
had to rely on DOS to fix something that the GUI just couldn't do?

Programatically, we've got things pretty good in the world of GUI, and
objects, and all that wonderful stuff. Back in my TP7 days, woulda loved to
be able to implement displaying a button without having to draw it, watch
for a click on that button, worry about redrawing the mouse every time it
moves, redraw a the button on a click, WATCH for the click, so on and so on.
Now? Two clicks, one double-click, and voila, we've got it made.

"J French" <erewhon@nowhere.com> wrote in message
news:4004f7ab.84615809@news.btclick.com...[color=blue]
> On Tue, 13 Jan 2004 07:19:57 -0800, "Sam Hobbs" <samuel*socal.rr.com>
> wrote:
>
> <snip>
>[color=green]
> >
> >Yes, a DOS TSR is very primitive, just as DOS is primitive. DOS TSRs are[/color][/color]
a[color=blue][color=green]
> >bad example but the important thing is to make it clear that "First we[/color][/color]
had[color=blue][color=green]
> >components... and now services." is the result of a huge[/color][/color]
misunderstanding.[color=blue][color=green]
> >Unless I misunderstand what is meant by "components", the valididty of[/color][/color]
that[color=blue][color=green]
> >statement is so far from the truth that it must be corrected.[/color]
>
> Agreed[/color]

You only talk about the UI. We were talking about the insides. Most
programmers that do most of their work with the internal complexities don't
care much about the UI. We often prefer to just do a simple command-line
interface instead of all that UI stuff. A UI often takes time but is not
much of a challenge.

The good stuff that DOS lacks is processes, events, semaphores, threads,
memory management, dynamic linking, timer/timing services, installable file
systems (not just a FAT one) and many other things that use those things.
DOS provides very little device independence, such as what a printer device
driver provides. One advantage of a GUI is that it can (and does) even
support a standard interface to printers for even text-only data.

When viewing DOS the way I do, it is very primitive.


"Stephen" <camarolt87@not.h0tmail.com> wrote in message
news:101qor8nb9hs33e@corp.supernews.com...[color=blue]
> I don't see DOS as totally primitavely as some do. DOS (Be it the Disk
> Access System, or MS-DOS or any flavor of the sort) are solid, proven
> methods of navigating. Even the 'nix clients use a command prompt.
>
> Now, before anyone goes up rear about my ignorance, or whatever, GUI of[/color]
any[color=blue]
> flavour is definately superior in the mannor of being able to display
> information in a more pleasing way, but, I can't count how many times I've
> had to rely on DOS to fix something that the GUI just couldn't do?
>
> Programatically, we've got things pretty good in the world of GUI, and
> objects, and all that wonderful stuff. Back in my TP7 days, woulda loved[/color]
to[color=blue]
> be able to implement displaying a button without having to draw it, watch
> for a click on that button, worry about redrawing the mouse every time it
> moves, redraw a the button on a click, WATCH for the click, so on and so[/color]
on.[color=blue]
> Now? Two clicks, one double-click, and voila, we've got it made.[/color]

be careful ... DOS does not mean "command line interface (CLI)"
CLIs are great, DOS is not.

--
Louis Solomon
[url]www.steelbytes.com[/url]

"Stephen" <camarolt87@not.h0tmail.com> wrote in message
news:101qor8nb9hs33e@corp.supernews.com...[color=blue]
>I don't see DOS as totally primitavely as some do. DOS (Be it the Disk
> Access System, or MS-DOS or any flavor of the sort) are solid, proven
> methods of navigating. Even the 'nix clients use a command prompt.
>
> Now, before anyone goes up rear about my ignorance, or whatever, GUI of
> any
> flavour is definately superior in the mannor of being able to display
> information in a more pleasing way, but, I can't count how many times I've
> had to rely on DOS to fix something that the GUI just couldn't do?
>
> Programatically, we've got things pretty good in the world of GUI, and
> objects, and all that wonderful stuff. Back in my TP7 days, woulda loved
> to
> be able to implement displaying a button without having to draw it, watch
> for a click on that button, worry about redrawing the mouse every time it
> moves, redraw a the button on a click, WATCH for the click, so on and so
> on.
> Now? Two clicks, one double-click, and voila, we've got it made.
>
> "J French" <erewhon@nowhere.com> wrote in message
> news:4004f7ab.84615809@news.btclick.com...[color=green]
>> On Tue, 13 Jan 2004 07:19:57 -0800, "Sam Hobbs" <samuel*socal.rr.com>
>> wrote:
>>
>> <snip>
>>[color=darkred]
>> >
>> >Yes, a DOS TSR is very primitive, just as DOS is primitive. DOS TSRs are[/color][/color]
> a[color=green][color=darkred]
>> >bad example but the important thing is to make it clear that "First we[/color][/color]
> had[color=green][color=darkred]
>> >components... and now services." is the result of a huge[/color][/color]
> misunderstanding.[color=green][color=darkred]
>> >Unless I misunderstand what is meant by "components", the valididty of[/color][/color]
> that[color=green][color=darkred]
>> >statement is so far from the truth that it must be corrected.[/color]
>>
>> Agreed[/color]
>
>[/color]

On Sun, 1 Feb 2004 16:25:51 -0800, "Sam Hobbs" <samuel*socal.rr.com>
wrote:
[color=blue]
>You only talk about the UI. We were talking about the insides. Most
>programmers that do most of their work with the internal complexities don't
>care much about the UI. We often prefer to just do a simple command-line
>interface instead of all that UI stuff. A UI often takes time but is not
>much of a challenge.
>
>The good stuff that DOS lacks is processes, events, semaphores, threads,
>memory management, dynamic linking, timer/timing services, installable file
>systems (not just a FAT one) and many other things that use those things.
>DOS provides very little device independence, such as what a printer device
>driver provides. One advantage of a GUI is that it can (and does) even
>support a standard interface to printers for even text-only data.
>
>When viewing DOS the way I do, it is very primitive.[/color]

You want to be very careful, there is a form of 'DOS' under the GUI
stuff in Windows
- the GUI stuff is basically a presentation layer

"J French" <erewhon@nowhere.com> wrote in message
news:401e0e9d.762745@news.btclick.com...[color=blue]
> On Sun, 1 Feb 2004 16:25:51 -0800, "Sam Hobbs" <samuel*socal.rr.com>
> wrote:
>[color=green]
> >You only talk about the UI. We were talking about the insides. Most
> >programmers that do most of their work with the internal complexities[/color][/color]
don't[color=blue][color=green]
> >care much about the UI. We often prefer to just do a simple command-line
> >interface instead of all that UI stuff. A UI often takes time but is not
> >much of a challenge.
> >
> >The good stuff that DOS lacks is processes, events, semaphores, threads,
> >memory management, dynamic linking, timer/timing services, installable[/color][/color]
file[color=blue][color=green]
> >systems (not just a FAT one) and many other things that use those things.
> >DOS provides very little device independence, such as what a printer[/color][/color]
device[color=blue][color=green]
> >driver provides. One advantage of a GUI is that it can (and does) even
> >support a standard interface to printers for even text-only data.
> >
> >When viewing DOS the way I do, it is very primitive.[/color]
>
> You want to be very careful, there is a form of 'DOS' under the GUI
> stuff in Windows
> - the GUI stuff is basically a presentation layer[/color]

Yes, we must be very careful about what we say. That is why I wrote my
"Console Applications" article at:

[url]http://simplesamples.info/Beginners/Consoles.php[/url]