|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Re: Multithreading> ... FACK> The truth behind all that "new" stuff is, that MS needs > "good reasons", to be able to sell their "new things" - > and stable ABIs/APIs are contradictory to that in > the long run. > > A developer can take influence on that only by ignorance > IMO - so that's what I'm doing - and many others do too. > Those who jump on the .NET-bandwagon only confirm/ > encourage MS to; "yeah, go further" with that strategy, > ending up "in the clouds" presumably. > Show quoteHide quote > ... Aah, repeating my all time sermon? :-))> ..NET is mainly a class-wrapper of the original system-apis - > ....nothing wrong with class-wrappers - but why on earth > has my program to fire up a VM, using (managed) code, based > on "new languages" to be able to make use of that classes? > Why not the conventional calling-conventions too (or if > classes are exposed, then unmanaged C++ interfaces, > or even COM)? > Why is everything included in such a huge package - why not > topic-oriented, smaller libraries, shipped (silently) as part of > the OS, each one maintained separately, not dependent on > the release-cycles of "a whole blob", slower evolving, not > breaking stuff that often, because the functionality is more isolated. > Interfaces to these new libraries available to all languages - > not only the "managed ones" (e.g. what's wrong with COM- > interfaces, usable without firing up a VM, just to be able to > call for example a simple "ping-function" or to draw a nice > rendered button). > > MS has done that already with the COM-wrapper-libs > for DirectX, to give an example - these small interface-libs > (after re-installing them) work even against the newest > DirectX-version that comes with Vista. > > It's a shame, that MS (which makes heavy use of COM > yet) does not provide *official* COM-interfaces for their > new helper-(interface-)libs - as for example against GDI+). > "Ulrich Korndoerfer" <ulrich_wants_nospam@prosource.de> schrieb im LOL, yes - I remember now that you wrote something inNewsbeitrag news:%23L1N4Nu6JHA.5008@TK2MSFTNGP05.phx.gbl... > > It's a shame, that MS (which makes heavy use of COM > > yet) does not provide *official* COM-interfaces for their > > new helper-(interface-)libs - as for example against GDI+). > > > > Aah, repeating my all time sermon? :-)) that regard already - but you were preaching the choir there of course. :-) I also understand, that VB-compatible COM-Interfaces need some special attention (regarding Type-mapping of the larger C++"COM-type-space" to the reduced one, available within VB-COM). But a large part of that could be automated by defining appropriate mapping-rules in the build-process of such interface-libs. But we have to live without that as it is now - writing wrappers ourselfes - and since that takes some effort in either case - then why not wrap Non-MS-Libs at this occassion - and that's what I also try. Olaf Schmidt schrieb:
> ... Yeah. Also, if building and fine tuning a COM server wrapper for an OS > I also understand, that VB-compatible COM-Interfaces need > some special attention (regarding Type-mapping of the larger > C++"COM-type-space" to the reduced one, available > within VB-COM). > > But a large part of that could be automated by defining > appropriate mapping-rules in the build-process of such > interface-libs. > dll is too much work for MS (because they are busy writing new .NET stuff), they at least should provide a typelib for the standard calls into these dlls (including the declarations for the structs, consts, enums etc of course). Those could be build automatically during their normal build process for the dll. Overall a typelib is nothing more than a more user friendly replacement of a bunch of C header files. VB happily can consume nearly any typelib of such kind. And C and C++ programmers would profit too from this. There is absolutely no excuse for MS there in doing not so (except for marketing reasons ;-). But this again is one of my long time sermons :-) > But we have to live without that as it is now - writing This of course makes sense, especially because there are Open Source > wrappers ourselfes - and since that takes some effort > in either case - then why not wrap Non-MS-Libs at this > occassion - and that's what I also try. libs available that outperform MS stuff (thinking eg of Cairo, Pango, SQLite to some extent etc). Wrapping a dll however always should start with making a typelib. Then, if for whichever reason, further development of the wrapper dll stalls, at least the typelib would be there, being a point where others could jump in. The only drawback of using typelibs is, that one looses fine control over where to get the wrapped dll from, because the wrapped dll is loaded on wrapper dll start by the operating systems program loader, using its search path. It is not possible then to load in ones own program in advance the dll to be wrapped from any place one wants. One has to put the wrapped dll at a place in the system's search path, which usually contains the application dir and the system dir. However this restriction is artificial, and MS could make a remedy for this. Hi Ulrich,
Show quoteHide quote "Ulrich Korndoerfer" <ulrich_wants_nospam@prosource.de> wrote in message That's a gross over exaggeration, combined with a bit of let's spin it as a news:e3oYVJv6JHA.1568@TK2MSFTNGP06.phx.gbl... > Schmidt schrieb: > > Yeah. Also, if building and fine tuning a COM server wrapper for an OS dll > is too much work for MS (because they are busy writing new .NET stuff), > they at least should provide a typelib for the standard calls into these > dlls (including the declarations for the structs, consts, enums etc of > course). Those could be build automatically during their normal build > process for the dll. Overall a typelib is nothing more than a more user > friendly replacement of a bunch of C header files. > > VB happily can consume nearly any typelib of such kind. And C and C++ > programmers would profit too from this. > > There is absolutely no excuse for MS there in doing not so (except for > marketing reasons ;-). But this again is one of my long time sermons :-) > conspiracy. MS has never provided complete windows API's as type libraries, as that is not what type libraries are for. There is not a one to one match between a C or C++ header file and a type library, anyone who has worked with GDI+ for example with type libraries can testify to that. And if this task was so simple to automate, then surely given that for years and years and year, Microsoft has released the C++ header files with the Windows SDK's, then other people would automate it.
Show quote
Hide quote
"Ulrich Korndoerfer" <ulrich_wants_nospam@prosource.de> skrev i meddelandet In my world, clouds sooner or later build-up to hailstorms and rain.news:%23L1N4Nu6JHA.5008@TK2MSFTNGP05.phx.gbl... > >> ... >> The truth behind all that "new" stuff is, that MS needs >> "good reasons", to be able to sell their "new things" - >> and stable ABIs/APIs are contradictory to that in >> the long run. >> >> A developer can take influence on that only by ignorance >> IMO - so that's what I'm doing - and many others do too. >> Those who jump on the .NET-bandwagon only confirm/ >> encourage MS to; "yeah, go further" with that strategy, >> ending up "in the clouds" presumably. >> > > FACK > > >> ... >> ..NET is mainly a class-wrapper of the original system-apis - >> ....nothing wrong with class-wrappers - but why on earth >> has my program to fire up a VM, using (managed) code, based >> on "new languages" to be able to make use of that classes? >> Why not the conventional calling-conventions too (or if >> classes are exposed, then unmanaged C++ interfaces, >> or even COM)? >> Why is everything included in such a huge package - why not >> topic-oriented, smaller libraries, shipped (silently) as part of >> the OS, each one maintained separately, not dependent on >> the release-cycles of "a whole blob", slower evolving, not >> breaking stuff that often, because the functionality is more isolated. >> Interfaces to these new libraries available to all languages - >> not only the "managed ones" (e.g. what's wrong with COM- >> interfaces, usable without firing up a VM, just to be able to >> call for example a simple "ping-function" or to draw a nice >> rendered button). >> >> MS has done that already with the COM-wrapper-libs >> for DirectX, to give an example - these small interface-libs >> (after re-installing them) work even against the newest >> DirectX-version that comes with Vista. >> >> It's a shame, that MS (which makes heavy use of COM >> yet) does not provide *official* COM-interfaces for their >> new helper-(interface-)libs - as for example against GDI+). >> > > Aah, repeating my all time sermon? :-)) > > -- > Ulrich Korndoerfer > > VB tips, helpers, solutions -> http://www.proSource.de/Downloads/ http://www.microsoft.com/presspass/features/2001/mar01/03-19hailstorm.mspx /Henning > In my world, clouds sooner or later build-up to hailstorms and rain. Fortunately "hailstorm" was hail-damaged :-)> http://www.microsoft.com/presspass/features/2001/mar01/03-19hailstorm.mspx "Ulrich Korndoerfer" <ulrich_wants_nospam@prosource.de> skrev i meddelandet And hopefully the new clouds will come down as rain. ;)news:eKwRMUv6JHA.1568@TK2MSFTNGP06.phx.gbl... >> In my world, clouds sooner or later build-up to hailstorms and rain. >> http://www.microsoft.com/presspass/features/2001/mar01/03-19hailstorm.mspx > > Fortunately "hailstorm" was hail-damaged :-) > > -- > Ulrich Korndoerfer > > VB tips, helpers, solutions -> http://www.proSource.de/Downloads/ /Henning |
|||||||||||||||||||||||
Other interesting topics