Of course you don't need COM+, in the same way that you don't need any of the Standard C library. It's just that having the framework in place expedites development (tho' we all know that Real Programmers are called Mel and write pure machine code on Royal McBee drum-memory machines...).
Given, I assume, that we're all convinced of the benefits of doing as little work as possible comcommitant with getting the product as specified out of the door on time (a viewpoint which I'll call "don't reinvent the fscking wheel" or "why work 80 hours/week when you can work 60"), the target then becomes "how can I leverage as much of other people's code as possible in order to help me do my job". Now, I've read Gray and Reuter. I could, given sufficient time, build a TM (those people who don't know what a TM is had better stop reading now and go back to tweaking their KDE themes or whatever). I could possibly, given sufficient time, write a TM that manages transactions across multiple distributed datastores (equally, a suitably large number of monkeys will write Hamlet). However, I don't need to do this because my middleware does it for me. Similarly, it handles queuing, event architectures, distrubuted processing, load balancing, clustering etc
This is why I chose to use middleware. Now, in answer to the second half of the question - why use a component-oriented middleware? Because, to put it bluntly, CLIs suck (I'm referring here to call-level interfaces, not command lines. Put those flames out now). CLIs are generally not language-neutral (vis Perl->wrapper->library of Perl routines written in C) or architecture-neutral (is an int 16, 18, 32 or 36 bits? How long's a char? How much accuracy do I get with a float? Does the system I'm communicating with do ASCII or Unicode or some MBCS such as Hangul?). They generally (there are notable exceptions) handle discovery very badly (i.e. can clients ask "what members do you have"?). They're often not location-neutral (i.e a call to a local component is often subtly, or even completely, different to one to a remote component). They're, to put it bluntly, nastier than they need be.
What COM does (and what EJB and the CCM do) is abstract a lot of these problems away (admittedly EJB cheats somewhat by making everyone talk Java: there is a COM - EJB bridge but to be honest, it's pants. You can't trivially mix apples and oranges, and you're better off not trying. Decide on one middleware architecture early on in your projects and stick to it. Madness lies elsewhere. There are also COM - CORBA and CORBA - EJB bridges too, but a) I've not used them in anger and b) they're probably going to become obsoleted fairly soon once the CCM starts permeating through (always assuming that the LOIs that members of the OMG signed up to actually get followed through).). All three provide some form of lifetime management, interception, load-balancing, transaction management and, in general save you from having to write all that grungy code yourself.
Finally, why use COM+? Well, because it's arguably the best component orientated middleware out there. There are legitimate arguments for EJB but it's got a number of fundamental problems, most of which I'm happy to discuss at length: put briefly, it's got all the political problems of COM+, it's got its own set of architectural problems (contrary to what some people may claim, stateful components are not a good idea. Ever.), it's relatively immature and it mandates that you write components in Java. CCM (the CORBA Component Model, sired by the loins of the OMG) may prove to be nice but since I've not yet seen a working implementation I'm reserving judgement. As far as I can tell from reading the documentation from the OMG, it looks like the EJB-aligned vendors wanted EJB to be accepted as an OMG standard as is, various other vendors wanted something a little more sensible and the resulting spec bears the scars.
Oh, and two warnings. First off, traditional CORBA, and bastardised COM implementations like Bonobo and KParts, bear as much resemblance to COM+ as the original VW Beetle does to the new one: the general concepts are the same (a wheel on each corner, an engine and a body) but there's not many other similarities. Secondly, not all CORBA vendors' objects are equal: it was only recently that they came up with IIOP. Previous to that, inter-ORB communication was... erm... interesting, at best. IIRC, CCM OTOH mandates RMI over IIOP and should therefore aid the chances of creating interoperable components - once it condenses from vapour into real products.
To tell the truth, I like multicolumn printing as a way of getting maximum amount of code onto the minimum amount of paper when I'm printing something to scribble over and try and fix... -- Cheers
Half-way there: continue to join the dots. My guess is that the underlying platform is based on the URP (Universal Runtime Platform) which VB, VJ++ and C# will all be targeted to. It'll also contain a lot of the guts of the products which were wrapped together to form Microsoft DNA: COM+, OLEDB, MAPI, the SOAP stuff etc. Result: an end-run round the DOJ and all approved by TPJ.
OSCo won't be going away for a while though: they still own the only viable desktop gaming platform (note the use of the word viable). And of course the whole NGWS/URP will run best on Windows. -- Cheers
I haven't seen Don Knuth posting round here, or ken or dmr for that matter. Since the mixture of individuals frequenting Slashdot is probably about 60% OSS/free software wannabes (i.e. can install Mandrake from CD and believes in his or her right to free MP3s), 10% BSD admins/hackers, 10% Linux admins/hackers, 15% Windows admins/hacker and 5% others (note that these figures come straight off the top of my head and have no scientific backing whatsoever), it is hardly suprising that they're anti-Microsoft. -- Cheers
The answer is that this comment is aimed at the middleware market, where the competition's currently EJB vs. COM+ (with CORBA - specifically the CORBA Component Model - currently a fairly vaporous alternative) If you want to write EJB, you're stuck with Java: COM components, OTOH, can be written in any language (more or less - I haven't seen Befunge, Intercal or Brainfuck wrappers yet:-). The point of this rambling is that C# components will be interoperable with Java components, COBOL components, VB components, C components, C++ components etc while EJBs aren't. -- Cheers
Well, you (and a lot of other people on this thread, but yours was the most blatant example) are confusing Java the programming language with Java the operating environment. In the same way that GCC embraces and extends standard C and C++ (IIRC, nested functions aren't part of standard C), Microsoftr took the Java language (not the Java runtime environment) and extended it so it was better suited for programming Windows.
Go away, learn IBM COBOL (as used on MVS), learn ICL COBOL (as used on George 3), and then come and talk about language pollution:-) -- Cheers
We've been known to call them "septics" - septic tanks - Yanks (the rest of the formation, and the subtexts, are left as an exercise for the reader) -- Cheers
... that can do whatever you need, when you need it, while the Windows user is lost when his narrow GUI doesn't offer a checkbox for what he needs.
No, the Windows developer goes to the command line when he or she has to because what he or she is trying to do is done better under a command line that through a GUI. Unlike the Linux user who hasn't got the option due to the general level of nastiness in most Linux IDEs (and an IDE built on top of an unstable windowing system like X is an accident waiting to happen).
What exactly is "productive" about rebooting because your beta app crashed the system or you're not sure whether the app might work after a reboot?
Let's see: I last rebooted this box (NT4 on Intel) about three days ago because I managed to utterly munge the SCM. Unsuprisingly, it was my fault - I was hacking on some of my service (== daemon) installation code and I managed to break it sufficiently to make me reboot the box so I could run it again. I can't remember when I last crashed the system and since my event log's wrapped round, I can't look it up.
debugging a web page, its server side scripts, its client side scripts, and binary server side code simultaneously).
On Unix, you can do as many things simultaneously as your mind can handle, and that is the only barrier.
What's being referred to here is the way in which I can step through an ASP and the browser page it generates, move seamlessly into stepping through a COM component written in VB, into another one written in C++, into another one written in <insert your favourite COM-authoring language here> and then onwards into a ISAPI DLL written in C. There is (to the best of my knowledge) no tools under Linux to allow me to do this: sure I can spawn a dozen copies of gdb or equivalent, but it isn't the same.
What exactly have badly documented system calls to do with a "component architecture"?
TRhe original question (it's up there in the title bar) was "Why Develop On Linux?". Comments about the utility of a language-neutral architecture-neutral OS-neutral binary-compatible component architecture vs. source-level code sharing are highly relevant. -- Cheers
Well, if the code I'm debugging throws an exception my OS opens it, on request, in the debugger with the line that caused it to blow up highlighted, thereby saving me the effort of wading through a core dump. Then, as you say, set a breakpoint and go. Doesn't your OS allow you to do that</innocent wide-eyed wonderment> -- Cheers
Unsuprising, really: why bother porting the nasty Linux knockoffs of Windows/Mac software (c.f. Gimp and Photoshop) when you can get the original. It's like working on cygwin to make sure it runs under WINE:-)
Parameters to main() are optional. From the standard (section 3.6.1 para.2)
"An implementation shall not predefine the main function. This function shall not be overloaded. It shall have a return type of type int, but otherwise its type is implementation-defined. All implementations shall allow both of the following definitions of main:
int main() {/*... */ }
and
int main(int argc, char* argv[]) {/*... */ }"
After all, if you don't expect any parameters or want them, why have the startup stub handle them
As for the use of modifiers, the declaration for WinMain is:
int WINAPI WinMain( HINSTANCE hInstance,// handle to current instance HINSTANCE hPrevInstance,// handle to previous instance LPSTR lpCmdLine,// command line int nCmdShow// show state );
where WINAPI is #define'd as __stdcall, which, in turn, is a compiler directive saying that the callee should clean the stack. This is the standard calling convention under Windows unless you've told your compiler to use __cdecl for all calls which haven't been made explicit, so in the vast majority of cases int WinMain is a legitimate construct. -- Cheers
Agreed, although given the nature of the software life cycle (god, I hate that phrase), it's rarely a case of making software maintenance free as making it easily maintainable: requirements change and (small) changes in requirements shouldn't require large changes in the code-base if the software's been designed correctly. -- Cheers
I know that it is possible to get multiple virtual desktops for Windows (if you pay a fee)
I, on the other hand, know it's possible to get multiple virtual desktops for Windows for free: just download the resource kit from Microsoft. FUD FUD FUD.
I'd agree with you though: MFC's shocking, which is why I don't use it. -- Cheers
Which was my point: having to manually flow and balance text isn't (IMHO) a usable solution - add a new column, spend the next half-hour reformatting your text. Change one of your styles and start again from scratch. Yeech. -- Cheers
There's two cow books: RoC++ by Koenig and Moo, AW Press, and Practical C Programming by Steve Oualline. Oualline's a beginner's text - what's C, why shoudl I program in it, what does (*(fp)(void)) mean etc.
RoC++ is more of a tour round some of the more interesting bits of C++ by a couple of the Bell Labs vets (and, as a bonus, features a recursive cover picture): it's a nice companion to C Traps and Pitfalls.
Hope this clears any misunderstandings up:-) -- Cheers
I'm more interested in how to write the best solution in the best method possible than how to write readable, maintainable code quickly.... I'm a programmer
No you're not: in my book you're a liability -- Cheers
Slashdot Mirror
What - expect people to know how a language works? Surely not - you'll be expecting them to know where the Any key is next.
--
Cheers
Given, I assume, that we're all convinced of the benefits of doing as little work as possible comcommitant with getting the product as specified out of the door on time (a viewpoint which I'll call "don't reinvent the fscking wheel" or "why work 80 hours/week when you can work 60"), the target then becomes "how can I leverage as much of other people's code as possible in order to help me do my job". Now, I've read Gray and Reuter. I could, given sufficient time, build a TM (those people who don't know what a TM is had better stop reading now and go back to tweaking their KDE themes or whatever). I could possibly, given sufficient time, write a TM that manages transactions across multiple distributed datastores (equally, a suitably large number of monkeys will write Hamlet). However, I don't need to do this because my middleware does it for me. Similarly, it handles queuing, event architectures, distrubuted processing, load balancing, clustering etc
This is why I chose to use middleware. Now, in answer to the second half of the question - why use a component-oriented middleware? Because, to put it bluntly, CLIs suck (I'm referring here to call-level interfaces, not command lines. Put those flames out now). CLIs are generally not language-neutral (vis Perl->wrapper->library of Perl routines written in C) or architecture-neutral (is an int 16, 18, 32 or 36 bits? How long's a char? How much accuracy do I get with a float? Does the system I'm communicating with do ASCII or Unicode or some MBCS such as Hangul?). They generally (there are notable exceptions) handle discovery very badly (i.e. can clients ask "what members do you have"?). They're often not location-neutral (i.e a call to a local component is often subtly, or even completely, different to one to a remote component). They're, to put it bluntly, nastier than they need be.
What COM does (and what EJB and the CCM do) is abstract a lot of these problems away (admittedly EJB cheats somewhat by making everyone talk Java: there is a COM - EJB bridge but to be honest, it's pants. You can't trivially mix apples and oranges, and you're better off not trying. Decide on one middleware architecture early on in your projects and stick to it. Madness lies elsewhere. There are also COM - CORBA and CORBA - EJB bridges too, but a) I've not used them in anger and b) they're probably going to become obsoleted fairly soon once the CCM starts permeating through (always assuming that the LOIs that members of the OMG signed up to actually get followed through).). All three provide some form of lifetime management, interception, load-balancing, transaction management and, in general save you from having to write all that grungy code yourself.
Finally, why use COM+? Well, because it's arguably the best component orientated middleware out there. There are legitimate arguments for EJB but it's got a number of fundamental problems, most of which I'm happy to discuss at length: put briefly, it's got all the political problems of COM+, it's got its own set of architectural problems (contrary to what some people may claim, stateful components are not a good idea. Ever.), it's relatively immature and it mandates that you write components in Java. CCM (the CORBA Component Model, sired by the loins of the OMG) may prove to be nice but since I've not yet seen a working implementation I'm reserving judgement. As far as I can tell from reading the documentation from the OMG, it looks like the EJB-aligned vendors wanted EJB to be accepted as an OMG standard as is, various other vendors wanted something a little more sensible and the resulting spec bears the scars.
Oh, and two warnings. First off, traditional CORBA, and bastardised COM implementations like Bonobo and KParts, bear as much resemblance to COM+ as the original VW Beetle does to the new one: the general concepts are the same (a wheel on each corner, an engine and a body) but there's not many other similarities. Secondly, not all CORBA vendors' objects are equal: it was only recently that they came up with IIOP. Previous to that, inter-ORB communication was ... erm ... interesting, at best. IIRC, CCM OTOH mandates RMI over IIOP and should therefore aid the chances of creating interoperable components - once it condenses from vapour into real products.
Hope this clarifies the situation.
--
Cheers
Is the US telephone system stillcircuit switched? Surely everyone's on PSTN by now.
--
Cheers
To tell the truth, I like multicolumn printing as a way of getting maximum amount of code onto the minimum amount of paper when I'm printing something to scribble over and try and fix...
--
Cheers
OSCo won't be going away for a while though: they still own the only viable desktop gaming platform (note the use of the word viable). And of course the whole NGWS/URP will run best on Windows.
--
Cheers
I haven't seen Don Knuth posting round here, or ken or dmr for that matter. Since the mixture of individuals frequenting Slashdot is probably about 60% OSS/free software wannabes (i.e. can install Mandrake from CD and believes in his or her right to free MP3s), 10% BSD admins/hackers, 10% Linux admins/hackers, 15% Windows admins/hacker and 5% others (note that these figures come straight off the top of my head and have no scientific backing whatsoever), it is hardly suprising that they're anti-Microsoft.
--
Cheers
The answer is that this comment is aimed at the middleware market, where the competition's currently EJB vs. COM+ (with CORBA - specifically the CORBA Component Model - currently a fairly vaporous alternative) If you want to write EJB, you're stuck with Java: COM components, OTOH, can be written in any language (more or less - I haven't seen Befunge, Intercal or Brainfuck wrappers yet :-). The point of this rambling is that C# components will be interoperable with Java components, COBOL components, VB components, C components, C++ components etc while EJBs aren't.
--
Cheers
Go away, learn IBM COBOL (as used on MVS), learn ICL COBOL (as used on George 3), and then come and talk about language pollution :-)
--
Cheers
We've been known to call them "septics" - septic tanks - Yanks (the rest of the formation, and the subtexts, are left as an exercise for the reader)
--
Cheers
No, the Windows developer goes to the command line when he or she has to because what he or she is trying to do is done better under a command line that through a GUI. Unlike the Linux user who hasn't got the option due to the general level of nastiness in most Linux IDEs (and an IDE built on top of an unstable windowing system like X is an accident waiting to happen).
What exactly is "productive" about rebooting because your beta app crashed the system or you're not sure whether the app might work after a reboot?
Let's see: I last rebooted this box (NT4 on Intel) about three days ago because I managed to utterly munge the SCM. Unsuprisingly, it was my fault - I was hacking on some of my service (== daemon) installation code and I managed to break it sufficiently to make me reboot the box so I could run it again. I can't remember when I last crashed the system and since my event log's wrapped round, I can't look it up.
debugging a web page, its server side scripts, its client side scripts, and binary server side code simultaneously).
On Unix, you can do as many things simultaneously as your mind can handle, and that is the only barrier.
What's being referred to here is the way in which I can step through an ASP and the browser page it generates, move seamlessly into stepping through a COM component written in VB, into another one written in C++, into another one written in <insert your favourite COM-authoring language here> and then onwards into a ISAPI DLL written in C. There is (to the best of my knowledge) no tools under Linux to allow me to do this: sure I can spawn a dozen copies of gdb or equivalent, but it isn't the same.
What exactly have badly documented system calls to do with a "component architecture"?
TRhe original question (it's up there in the title bar) was "Why Develop On Linux?". Comments about the utility of a language-neutral architecture-neutral OS-neutral binary-compatible component architecture vs. source-level code sharing are highly relevant.
--
Cheers
Since when was part of the STL? It's part of the standard C++ library, but it's got nothing to do with the STL.
--
Cheers
Seconded: Textpad rocks.
--
Cheers
Well, if the code I'm debugging throws an exception my OS opens it, on request, in the debugger with the line that caused it to blow up highlighted, thereby saving me the effort of wading through a core dump. Then, as you say, set a breakpoint and go. Doesn't your OS allow you to do that</innocent wide-eyed wonderment>
--
Cheers
--
Cheers
"An implementation shall not predefine the main function. This function shall not be overloaded. It shall have a return type of type int, but otherwise its type is implementation-defined. All implementations shall allow both of the following definitions of main:
int main() { /* ... */ }
and
int main(int argc, char* argv[]) { /* ... */ }"
After all, if you don't expect any parameters or want them, why have the startup stub handle them
As for the use of modifiers, the declaration for WinMain is:
int WINAPI WinMain( // handle to current instance // handle to previous instance // command line // show state
HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow
);
where WINAPI is #define'd as __stdcall, which, in turn, is a compiler directive saying that the callee should clean the stack. This is the standard calling convention under Windows unless you've told your compiler to use __cdecl for all calls which haven't been made explicit, so in the vast majority of cases int WinMain is a legitimate construct.
--
Cheers
It should read int main()
--
Cheers
Agreed, although given the nature of the software life cycle (god, I hate that phrase), it's rarely a case of making software maintenance free as making it easily maintainable: requirements change and (small) changes in requirements shouldn't require large changes in the code-base if the software's been designed correctly.
--
Cheers
kill -f #pid. It's in the ResKit, free for download from the evil Microsoft - try reading the documentation some time before spouting off.
--
Cheers
I, on the other hand, know it's possible to get multiple virtual desktops for Windows for free: just download the resource kit from Microsoft. FUD FUD FUD.
I'd agree with you though: MFC's shocking, which is why I don't use it.
--
Cheers
Bollocks: kill it (see my post above)
--
Cheers
Killing a local service (if it won't respond to the SCM):
Stopping a remote service:
Killing a remote service:
Was it that difficult to read the documentation?
--
Cheers
...and if the rest of the world has tied itself to a single solution from a single vendor...
--
Cheers
Which was my point: having to manually flow and balance text isn't (IMHO) a usable solution - add a new column, spend the next half-hour reformatting your text. Change one of your styles and start again from scratch. Yeech.
--
Cheers
RoC++ is more of a tour round some of the more interesting bits of C++ by a couple of the Bell Labs vets (and, as a bonus, features a recursive cover picture): it's a nice companion to C Traps and Pitfalls.
Hope this clears any misunderstandings up :-)
--
Cheers
No you're not: in my book you're a liability
--
Cheers