Legacy Graphics

Acest forum este dedicat intrebarilor de Windows API, folosing C/C++
Cryogenic
Membru
Membru
Posts: 55
Joined: 30 Jun 2008, 17:43

Re: Legacy Graphics

Post by Cryogenic » 23 Jul 2011, 22:17

neagu_laurentiu wrote:
Cryogenic wrote:Ce componente COM consuma .Net-u? si de care ar fi dependent?
Am zis mai sus: OLEDB, WPF (via DirectX), dialog-urile (cele noi din Vista si 7) etc.
WPF intra in acea lista, intradevar WPF e construit peste DirectX, restul sunt complet optionale.
Dar .Net-ul poate bine mersi si functioneze si fara COM. Iar core .Net cu atat mai mult nu are nici o legatura cu COM decat pentru interop.



User avatar
Ovidiu Cucu
Fondator
Fondator
Posts: 3776
Joined: 11 Jul 2007, 16:10
Judet: Iaşi
Location: Iasi
Contact:

Re: Legacy Graphics

Post by Ovidiu Cucu » 24 Jul 2011, 09:39

Cryogenic wrote:
In afara de faptul ca expune DllGetClassObject, sau alte metode, intrebarea este: Ce componente COM consuma .Net-u? si de care ar fi dependent?
"What have the Romans ever done for us?"
"The aqueduct..."


Continuarea aici: http://www.youtube.com/watch?v=ExWfh6sGyso ;)

User avatar
Silviu Ardelean
Senior
Senior
Posts: 1175
Joined: 12 Jul 2007, 09:22
Judet: Timiş
Location: Timisoara
Contact:

Re: Legacy Graphics

Post by Silviu Ardelean » 24 Jul 2011, 10:49

Offtopic: Ce mult imi lipseste butonul Like! Ovidiu, aveai parte de cel putin 2 like-uri la threadul asta. :)

User avatar
Ovidiu Cucu
Fondator
Fondator
Posts: 3776
Joined: 11 Jul 2007, 16:10
Judet: Iaşi
Location: Iasi
Contact:

Re: Legacy Graphics

Post by Ovidiu Cucu » 24 Jul 2011, 12:05

Cryogenic wrote:
Ce componente COM consuma .Net-u? si de care ar fi dependent?
Acuma serios. Doar n-ai vrea ca apelurile la QueryInterface sa bage interfetele in lista de dependente.
Cum spuneam, COM-ul stie sa "ascunda sub tejghea", si asta e una dintre chestiile pe care i le-au ursit ursitoarele cand mama lui l-a facut.

Sa fiu un pic rautacios. Banui ca, atunci cand ajungem dependenti de un framework ca boschetarul de aurolac, cautam framework-uri peste tot.
No offense, nu numai programatorii .NET sufera de boala asta.
Pe scurt, COM (Component Object Model) NU e un framework, nu e o bibloteca, ci un model, o arhitectura, un pattern, zi cum vrei, care cuprinde niste specificatii pentru crearea de componente.

In fine, sa zicem... si sa trecem la framework-uri si biblioteci.
Ca sa nu ne mai certam, propun un schimb:
Eu iti scriu in C++ o componenta COM si o aplicatie client care nu depind nici direct nici indirect de vreo biblioteca OLExyz sau orice alta care sa contina OLE/COM stuff.
La schimb fa-mi te rog si tu in .NET ceva, nu conteaza ce, cu .NET sa fie, la care sa dispara OLExyz din lista de dependente.

Dupa aia, poate lamurim si ce-i cu, citez, "COM (Ole, ActiveX, COM+, ce o fi.)" pe care se pare ca unii teoreticieni .NET au cam inceput sa le amestece, iar copiii citesc si o iau de buna... ;)

Cryogenic
Membru
Membru
Posts: 55
Joined: 30 Jun 2008, 17:43

Re: Legacy Graphics

Post by Cryogenic » 24 Jul 2011, 21:54

Ovidiu Cucu wrote: Acuma serios. Doar n-ai vrea ca apelurile la QueryInterface sa bage interfetele in lista de dependente.
Apelul la QueryInterface tot returneaza o lista de interfete cunoscute cea ce duce la o lista de componente cunoscute. (Asta daca nu cumva vrei sa zici ca .Net-ul foloseste IDispatch si foloseste componente COM in mod dinamic.
Ovidiu Cucu wrote: Cum spuneam, COM-ul stie sa "ascunda sub tejghea", si asta e una dintre chestiile pe care i le-au ursit ursitoarele cand mama lui l-a facut.
Nu se ascunde sub nici o tejghea, COM e doar un standard binar care defineste strict interfetele si nu implementarea. Si daca o iei asa .Net poate fi considerata o technologie prin care poate sa se creeze componente COM (La fel si Java, Flash ... sau orice gogomanie ), insa ma repet de aici si pana la a fi construit "peste COM" e cale lunga. Vad ca-ti place teoria asta legata de ascunzis si tejghele, insa e doar o incercare de demonstratie teoretica a dependintei dintre cele doua bazata pe niste deductii false.
Ovidiu Cucu wrote: Sa fiu un pic rautacios. Banui ca, atunci cand ajungem dependenti de un framework ca boschetarul de aurolac, cautam framework-uri peste tot.
No offense, nu numai programatorii .NET sufera de boala asta.
Esti rautacios, dar din experienta mea era de asteptat sa se intample asta (in momentul cand esti prins cu matza in sac).
Ovidiu Cucu wrote: Pe scurt, COM (Component Object Model) NU e un framework, nu e o bibloteca, ci un model, o arhitectura, un pattern, zi cum vrei, care cuprinde niste specificatii pentru crearea de componente.
Nu retin sa te fi contrazis in aceasta privinta. Asa e, insa doar pentru ca .Net-ul poate interopera cu acest model, arhitectura, pattern, nu duce la concluzia ca ar fi construit peste COM. A fi construit peste, inseamna a avea o dependinta directa de aceasta technologie, model, arhitectura, si a consuma componente create folosing COM pentru a putea rula. Lucru care nu se intampla, cu exceptia unor librarii aditionale cum ar fi WPF care intradevar are o depedinta COM. Core .Net e independent de COM.
Ovidiu Cucu wrote: In fine, sa zicem... si sa trecem la framework-uri si biblioteci.
Ca sa nu ne mai certam, propun un schimb:
Eu iti scriu in C++ o componenta COM si o aplicatie client care nu depind nici direct nici indirect de vreo biblioteca OLExyz sau orice alta care sa contina OLE/COM stuff.
Grozav, dar tot depind de "model, o arhitectura, un pattern", deci aplicatia ta va fi bazata pe COM. Ca sa te parafrazez: "NO COM No Application", de fapt stai ca nu e asa in cazul aplicatie tale, ... dar oare in cazul .Net de ce e ?
Ovidiu Cucu wrote: La schimb fa-mi te rog si tu in .NET ceva, nu conteaza ce, cu .NET sa fie, la care sa dispara OLExyz din lista de dependente.
Gata!
Ovidiu Cucu wrote: Dupa aia, poate lamurim si ce-i cu, citez, "COM (Ole, ActiveX, COM+, ce o fi.)" pe care se pare ca unii teoreticieni .NET au cam inceput sa le amestece, iar copiii citesc si o iau de buna... ;)
Bine, lamureste-i pe copii ...
Silviu Ardelean wrote:Offtopic: Ce mult imi lipseste butonul Like! Ovidiu, aveai parte de cel putin 2 like-uri la threadul asta. :)
Eu zica ca e foarte bine ca lipseste "Butonul de pupat in ... ". Mi-e frica ca l-ai fi abuzat, ca ceva idee sau opinie utila oricum nu ai adus discutiei.

User avatar
Silviu Ardelean
Senior
Senior
Posts: 1175
Joined: 12 Jul 2007, 09:22
Judet: Timiş
Location: Timisoara
Contact:

Re: Legacy Graphics

Post by Silviu Ardelean » 24 Jul 2011, 22:10

Cryogenic wrote:
Silviu Ardelean wrote:Offtopic: Ce mult imi lipseste butonul Like! Ovidiu, aveai parte de cel putin 2 like-uri la threadul asta. :)
Eu zica ca e foarte bine ca lipseste "Butonul de pupat in ... ". Mi-e frica ca l-ai fi abuzat, ca ceva idee sau opinie utila oricum nu ai adus discutiei.
Ai lipsit dintre noi o buna perioada de timp si din pacate observ ca ai acelasi narav. Legat de opinie cred ca stii ce inseamna "offtopic".
Uite ce mult il pupam pe Ovidiu numai in urma cu cateva zile. De data asta mi-a placut si i-as fi dat cel putin un Like.

User avatar
Ovidiu Cucu
Fondator
Fondator
Posts: 3776
Joined: 11 Jul 2007, 16:10
Judet: Iaşi
Location: Iasi
Contact:

Re: Legacy Graphics

Post by Ovidiu Cucu » 25 Jul 2011, 09:36

Cryogenic wrote: Bine, lamureste-i pe copii ...
Bine, cu poze colorate... :)
Lectia 1. Copacelul .NET
Dot Net Application Dependency.jpg
Dot Net Application Dependency.jpg (25.16 KiB) Viewed 7293 times
Dragi copii,
Copacelul din poza e invers decat cel din gradina la bunica (are radacina sus si frunzulitele jos).
Asta pentru ca trebuie sa citim asa: DOTNETAPPLICATION.EXE sta pe (depinde de) MSCOREE.DLL care sta pe OLEAUT32.DLL care sta pe OLE32.DLL.
Daca la copacelul bunicii cade o frunzulita, nu se intampla nimic.
Daca insa la .NET cade o singura frunzulita (sa zicem OLE32.DLL), copacelul se usuca si moare. ;)

// @ pt. Cryogenic
La celelalte puncte din ultimul tau post, e greu sa-ti dea cineva acum un raspuns decent si de bun simt.
Sfatul meu prietenesc: fa o plimbare seara pe racoare ca sa te calmezi si sa devii coerent in ce spui! Dupa aia mai discutam.

tudor_t
Membru
Membru
Posts: 112
Joined: 26 Aug 2007, 15:11

Re: Legacy Graphics

Post by tudor_t » 25 Jul 2011, 10:22

neagu_laurentiu wrote:Technologies that are obsolete and should not be used in new applications.
http://msdn.microsoft.com/en-us/library ... 85%29.aspx
Ce e ciudat in lista aia e ... OpenGL - ca la Microsoft nu le place ca unii folosesc OpenGL e o chestie, da' din fericire nu ei hotarasc ca e 'obsolete'.. :)

tudor_t
Membru
Membru
Posts: 112
Joined: 26 Aug 2007, 15:11

Re: Legacy Graphics

Post by tudor_t » 25 Jul 2011, 10:24

neagu_laurentiu wrote:
Cryogenic wrote:Ce componente COM consuma .Net-u? si de care ar fi dependent?
Am zis mai sus: OLEDB ...
Nu am mai folosit de o gramada de vreme baze de date care sa nu aiba provider ADO.NET nativ si la care sa am nevie de providerul OleDB din ADO 'clasic'..

User avatar
Marius Bancila
Fondator
Fondator
Posts: 2344
Joined: 11 Jul 2007, 11:45
Judet: Timiş
Location: Timisoara
Contact:

Re: Legacy Graphics

Post by Marius Bancila » 25 Jul 2011, 11:30

Ovidiu, poza aia nu demonstreaza ca .NET e construit "peste" COM. Acolo e vorba de dependinte. Acuma depinde ce intelegi tu cu "sta peste COM" (asa orice aplicatie "sta peste" orice dependinta). Acuma daca prin "sta peste COM" intelegi ca .NET e COM, atunci nu e corect. Daca intelegi ca foloseste COM, atunci e corect.

Hai s-o lamurim asa: are nevoie .NET de COM. Raspunsul e NU. Ca si argument vezi MONO, care e cross-platform, merge pe Linux, Windows si Mac OS, si nu foloste COM. Acum, cand vine vorba de implementarea Microsoft a framework-ului .NET, tinand cont ca e pentru Windows si Windows foloseste COM la greu, sigur ca s-a ajuns ca .NET sa foloseasca COM. Acuma e .NET COM sau nu? Raspunsu e nu, chiar daca CLR-ul e implementat ca un COM server.
Jeffrey Richter wrote: The .NET Framework runs on top of Microsoft Windows. This means that the .NET Framework must be built using technologies that Windows can interface with. For starters, all managed module and assembly files must use the Windows portable executable (PE) file format and be either a Windows EXE file or a dynamic-link library (DLL).

When developing the CLR, Microsoft implemented it as a COM server contained inside a DLL; that is, Microsoft defined a standard COM interface for the CLR and assigned GUIDs to this interface and the COM server. When you install the .NET Framework, the COM server representing the CLR is registered in the Windows registry just as any other COM server. If you want more information about this topic, refer to the MSCorEE.h C++ header file that ships with the .NET Framework SDK. This header file defines the GUIDs and the unmanaged ICLRRuntimeHost interface definition.
(vezi CLR via C# de Jeffrey Richter, Capitolul 21, CLR Hosting and AppDomains)

Spun ca raspunsul e NU, pentru ca atunci cand instantiei un obiect .NET nu instantiezi (neaparat) un obiect COM. Prin urmare, .NET nu e COM. Insa da, sigur ca foloseste COM.

Asa s-ar putea agumenta, dupa cum zice cineva aici ca "it is all assembly underneath".
Marius Bancila
Fondator Codexpert, Microsoft MVP VC++
Site personal | Blog

viorel2005
Membru
Membru
Posts: 208
Joined: 24 May 2008, 09:41

Re: Legacy Graphics

Post by viorel2005 » 23 Aug 2011, 19:25

Eu iti scriu in C++ o componenta COM si o aplicatie client care nu depind nici direct nici indirect de vreo biblioteca OLE sau orice alta care sa contina OLE/COM stuff.
Intrebare: Se poate scrie o componenta COM si sa fie apelata in Linux? Din punct de vedere al dezvoltatorilor soft ar fi fost interesant sa vezi o componenta chart dezvoltata folosind COM pentru
Windows si Linux. Din pacate, programatorii de C++ au preferat sa foloseasca standardul C++ impreuna cu extensii proprietare. Si ceea ce este interesant este ca daca vrei sa faci un firewall in WIndows
este o problema fata de Linux unde totul este documentat. Si este normal deoarece un firewall de Linux nu aduce bani cum aduce un firewall de Windows. Mai mult se vorbeste de interoperabilitate COM,
dar singurul model adevarat de interoperabilitate este oferit de Java. Programarea COM nu a murit odata cu VB6 cum ar fi trebuit, sau cu Windows Vista/7. Pe de alta parte, daca s-a renuntat la programatorii de Foxpro si Vb6, poate intr-o zi vom avea si legacy COM,.NET si OLE DB impreuna cu abandonarea .NET.

neagu_laurentiu
Membru++
Membru++
Posts: 919
Joined: 23 Jul 2007, 11:32

Re: Legacy Graphics

Post by neagu_laurentiu » 23 Aug 2011, 21:00

COM-ul nu ruleaza sub Linux. Insa pentru Linux sunt tehnologii asemanatoare ca principiu. Exista si interoperabilitate in C++ la fel ca in Java dar nu cu tehnologii MS.

User avatar
Silviu Ardelean
Senior
Senior
Posts: 1175
Joined: 12 Jul 2007, 09:22
Judet: Timiş
Location: Timisoara
Contact:

Re: Legacy Graphics

Post by Silviu Ardelean » 23 Aug 2011, 22:47

viorel2005 wrote:
Eu iti scriu in C++ o componenta COM si o aplicatie client care nu depind nici direct nici indirect de vreo biblioteca OLE sau orice alta care sa contina OLE/COM stuff.
Mai mult se vorbeste de interoperabilitate COM, dar singurul model adevarat de interoperabilitate este oferit de Java.
Nu confunda interoperabilitatea cu portabilitatea.

viorel2005
Membru
Membru
Posts: 208
Joined: 24 May 2008, 09:41

Re: Legacy Graphics

Post by viorel2005 » 23 Aug 2011, 23:26

Nu confunda interoperabilitatea cu portabilitatea.
Totusi de la adresa:

http://java.sun.com/developer/onlineTra ... xamp.htmll
You can call code written in any programming language from a program written in the Java language by declaring a native Java method, loading the library that contains the native code, and then calling the native method. The ReadFile source code below does exactly this.
Deci java asigura interoperabilitate ca tehnologia COM si portabilitate prin intermediul JVM. Totusi, COM a fost inventat pentru modularizarea sistemului de operare OS, unde la nucleu au fost adaugate
diferite servicii pentru a creea diverse versiuni de Windows. Cu tot suportul adaugat la limbaj, scrierea unei componente COM nu este simpla. In schimb e simpla utilizarea sa in alte limbaje.

User avatar
Silviu Ardelean
Senior
Senior
Posts: 1175
Joined: 12 Jul 2007, 09:22
Judet: Timiş
Location: Timisoara
Contact:

Re: Legacy Graphics

Post by Silviu Ardelean » 24 Aug 2011, 10:36

Imi place thread-ul asta. S-a plecat de la tehnologii obsolete, s-a ajuns la managed vs. unmanaged in Windows, iar acum o luam mai pe ulei si ajungem la COM vs. tehnologii Java. Implicit ajungem la Portable object.

Daca tot vroiai sa faci o comparatie COM cu alte tehnologii similare cred ca mai potrivit decat JNI ar fi CORBA si Java Beans.
Nu am experienta cu Java Native Interface dar mie-mi pare mai mult o modalitate similara dll-urilor scrise in Delphi ce exporta interfata "C" si pot fi folosite din VC++ (si vice-versa).
JNI enables one to write native methods to handle situations when an application cannot be written entirely in the Java programming language, e.g. when the standard Java class library does not support the platform-specific features or program library.
Many of the standard library classes depend on JNI to provide functionality to the developer and the user, e.g. file I/O and sound capabilities. Including performance- and platform-sensitive API implementations in the standard library allows all Java applications to access this functionality in a safe and platform-independent manner.
The JNI framework lets a native method use Java objects in the same way that Java code uses these objects.

Pitfalls
an application that relies on JNI loses the platform portability Java offers (a workaround is to write a separate implementation of JNI code for each platform and have Java detect the operating system and load the correct one at runtime).
Unde mai e celebra portabilitatea Java (un cod ce ruleaza pe orice OS)? Si uite asa ajugem la framework-uri gen SWT.
Component Object Model (COM) it is used to enable interprocess communication and dynamic object creation in a large range of programming languages.
The essence of COM is a language-neutral way of implementing objects that can be used in environments different from the one in which they were created, even across machine boundaries.

Post Reply