Pregunta novato .NET Platform (COM, API, DLL)

En pocas palabras, todo lo que comentas es lo que, desde el mundo .NET se ha
dado en llamar código antiguo u obsoleto, que realmente no lo es y todavía
siguen haciéndose miles y miles de programas bajo esas tecnologías.

Un API es un Application Program Interface, o sea, un Interfaz para
Programación de Aplicaciones, o sea una serie de "cosas" disponibles para
construir programas.

Win32 es el API nativo u original de Windows. Son miles y miles de funciones
disponibles para que el programador las use y construya sus programas. Están
escritas en C y C++ y son el núcleo y centro de todos los Windows, incluso
el Vista. Esas funciones se agrupan en diferentes ficheros, conocidos como
DLLs y ejecutables.

Una DLL es un fichero que contiene un grupo de funciones o clases
empaquetados convenientemente. Digamos que es el concepto anterior a
ensamblado.

Un exe es un programa ejecutable -aunque no siempre, podría ser sólo una DLL
u otra cosa-.

Generalmente una aplicación "obsoleta" es un conjunto de DLLs, ficheros
varios y uno o más ejecutables. Es la forma tradicional de trabajar en
cualquier sistema operativo desde el principio de los tiempos (de hecho el
propio sistema operativo no es más que eso). Aplicaciones "obsoletas"
escritas con DLLs y EXEs son el Word, el PowerPoint, el Autocad, el Outlook
(el del Office y el Express), el Explorador de Windows, el bloc de notas, el
Visual Studio...

El "GetSystemInfo" que nombras es una función disponible en el API Win32,
igual que hay unos cuantos miles de ellas más y que ofrece Windows a los
programadores para que las llamen. Todo eso está documentado en la MSDN que
acompaña a tu Visual Studio y en la versión OnLine:
http://msdn2.microsoft.com/en-us/li...fault.aspx

La descripción de la función está aquí:
http://msdn2.microsoft.com/en-gb/li...4381.aspx, y verás que al final
te dice en qué fichero .H se ecuentra su definición y en qué DLL está
alojada.

COM es un modelo de compomentes o de programación, igual que el NET pero
algo más antigua; la idea es tener componentes y juntarlos de forma que
todos ellos formen una aplicación. Trabajar con COM de forma nativa es
enormemente complejo, y bajo .NET se ha simplificado bastante. Parecido a
juntar DLLs con EXEs y obtener una aplicación, pero los elementos COM son
"inteligentes" en el sentido de que se autodescriben y ofrecen interfaces
para su uso, digamos que es el origen de la reflexión en NET.

Y no pienses que el NET es la panacea de todas las panaceas, no es más que
una máquina virtual que ejecuta una serie de bibliotectas de igual forma que
el Java, y tampoco se trata de una biblioteca completa, si no no haría falta
utilizar código legado.

No dudes en preguntar más si no lo tienes claro.

Visita mi blog principal: http://rfog.blogsome.com
Y este sobre programaci?n: http://geeks.ms/blogs/rfog
Libros, ciencia ficcion y programacion
Hombre invisible busca mujer transparente para hacer lo nunca visto.

"Camilo" wrote in message
news:
Mostrar la cita

Saludos a todos los miembros de este grupo!

Estoy estudiando para obtener la certificación 70-305 (Desarrollar
aplicaciones web con .NET) y tengo algunas dudas conceptuales que
seguramente le serán muy fáciles de resolver a quienes tienen bastante
experiencia; mi problema es el siguiente: Cuando se habla de la plataforma
.NET, se habla de código administrado (managed code) a través del CLR. Sin
embargo, estoy estudiando que .NET provee algunas clases para interoperar
con COM y con EXE's y APISs, DLL's heredadas. La pregunta es: Que es
exactamente (en palabras cortas) cada una de estas cosas (COM, EXE's,
API's DLL's), y en especial, enque se diferencia COM de las DLL's o API´s
heredadas? Yo entiendo que una DLL es una librería, y un EXE es un
ejecutable, pero no entiendo que hay detrás de esto. Tampoco de COM (que
no corresponde con un tipo de archivos; lo que he leido hablan de un
modelo de programación, pero no logro aterrizar la idea).

Por otro lado, en uno de los ejemplos que he mirado ilustran como llamar
al procedimiento GetSystemInfo de la API "kernel32.dll". Por lo que veo,
uno debe conocer la DLL para poder saber que métodos invocar y qué
parametros proporcionar. Como sabe uno eso? Hay un mapa o algo donde uno
sepa cada DLL que "tiene por dentro"?

Mis dudas son simplemente conceptuales, y como soy nuevo en el mundo de la
programación no me interesa (por ahora al menos) conocer en detalle esto
del COM y amigos; simplemente quiero poder entender conceptualmente para
cuando se presente la necesidad de integrar una aplicación o utilizar una
DLL o un componente viejo.

Muchas gracias por la ayuda,


Camilo Arango

Hola Zephryn;

Muchas gracias por tu respuesta; quisiera hacerte algunas mas para
complementar, si no es mucha molestia;

1. Según lo que me dices, yo podría escribir (a la antigua) un programa con
un EXE y varios DLL's y constituir así una API también para, digamos,
facilitársela a algún tercero para que a su vez la utilice para escribir un
programa? En ese caso, mi API sería la definición de todo lo que he
implementado para él en mi EXE y mis DLL's?

2. No me queda muy claro que es el COM; es un modelo con el que un
programador trabaja, y va enlazando o referenciando componentes que va
necesitando a medida que va desarrollando su programa a través me imagino
del IDE, pero al final cuando compila obtiene también un EXE y unos DLL's
correcto? Y entonces que viene siendo las MFC (Microsoft Foundation
Classes)?

Gracias por tu ayuda!

Saludos,

Camilo



"RFOG" escribió en el mensaje
news:
Mostrar la cita

En pocas palabras, todo lo que comentas es lo que, desde el mundo .NET se
ha dado en llamar código antiguo u obsoleto, que realmente no lo es y
todavía siguen haciéndose miles y miles de programas bajo esas
tecnologías.

Un API es un Application Program Interface, o sea, un Interfaz para
Programación de Aplicaciones, o sea una serie de "cosas" disponibles para
construir programas.

Win32 es el API nativo u original de Windows. Son miles y miles de
funciones disponibles para que el programador las use y construya sus
programas. Están escritas en C y C++ y son el núcleo y centro de todos los
Windows, incluso el Vista. Esas funciones se agrupan en diferentes
ficheros, conocidos como DLLs y ejecutables.

Una DLL es un fichero que contiene un grupo de funciones o clases
empaquetados convenientemente. Digamos que es el concepto anterior a
ensamblado.

Un exe es un programa ejecutable -aunque no siempre, podría ser sólo una
DLL u otra cosa-.

Generalmente una aplicación "obsoleta" es un conjunto de DLLs, ficheros
varios y uno o más ejecutables. Es la forma tradicional de trabajar en
cualquier sistema operativo desde el principio de los tiempos (de hecho el
propio sistema operativo no es más que eso). Aplicaciones "obsoletas"
escritas con DLLs y EXEs son el Word, el PowerPoint, el Autocad, el
Outlook (el del Office y el Express), el Explorador de Windows, el bloc de
notas, el Visual Studio...

El "GetSystemInfo" que nombras es una función disponible en el API Win32,
igual que hay unos cuantos miles de ellas más y que ofrece Windows a los
programadores para que las llamen. Todo eso está documentado en la MSDN
que acompaña a tu Visual Studio y en la versión OnLine:
http://msdn2.microsoft.com/en-us/li...fault.aspx

La descripción de la función está aquí:
http://msdn2.microsoft.com/en-gb/li...4381.aspx, y verás que al
final te dice en qué fichero .H se ecuentra su definición y en qué DLL
está alojada.

COM es un modelo de compomentes o de programación, igual que el NET pero
algo más antigua; la idea es tener componentes y juntarlos de forma que
todos ellos formen una aplicación. Trabajar con COM de forma nativa es
enormemente complejo, y bajo .NET se ha simplificado bastante. Parecido a
juntar DLLs con EXEs y obtener una aplicación, pero los elementos COM son
"inteligentes" en el sentido de que se autodescriben y ofrecen interfaces
para su uso, digamos que es el origen de la reflexión en NET.

Y no pienses que el NET es la panacea de todas las panaceas, no es más que
una máquina virtual que ejecuta una serie de bibliotectas de igual forma
que el Java, y tampoco se trata de una biblioteca completa, si no no haría
falta utilizar código legado.

No dudes en preguntar más si no lo tienes claro.

Visita mi blog principal: http://rfog.blogsome.com
Y este sobre programaci?n: http://geeks.ms/blogs/rfog
Libros, ciencia ficcion y programacion
> Hombre invisible busca mujer transparente para hacer lo nunca visto.

"Camilo" wrote in message
news:
Mostrar la cita

Saludos a todos los miembros de este grupo!

Estoy estudiando para obtener la certificación 70-305 (Desarrollar
aplicaciones web con .NET) y tengo algunas dudas conceptuales que
seguramente le serán muy fáciles de resolver a quienes tienen bastante
experiencia; mi problema es el siguiente: Cuando se habla de la
plataforma .NET, se habla de código administrado (managed code) a través
del CLR. Sin embargo, estoy estudiando que .NET provee algunas clases
para interoperar con COM y con EXE's y APISs, DLL's heredadas. La
pregunta es: Que es exactamente (en palabras cortas) cada una de estas
cosas (COM, EXE's, API's DLL's), y en especial, enque se diferencia COM
de las DLL's o API´s heredadas? Yo entiendo que una DLL es una librería,
y un EXE es un ejecutable, pero no entiendo que hay detrás de esto.
Tampoco de COM (que no corresponde con un tipo de archivos; lo que he
leido hablan de un modelo de programación, pero no logro aterrizar la
idea).

Por otro lado, en uno de los ejemplos que he mirado ilustran como llamar
al procedimiento GetSystemInfo de la API "kernel32.dll". Por lo que veo,
uno debe conocer la DLL para poder saber que métodos invocar y qué
parametros proporcionar. Como sabe uno eso? Hay un mapa o algo donde uno
sepa cada DLL que "tiene por dentro"?

Mis dudas son simplemente conceptuales, y como soy nuevo en el mundo de
la programación no me interesa (por ahora al menos) conocer en detalle
esto del COM y amigos; simplemente quiero poder entender conceptualmente
para cuando se presente la necesidad de integrar una aplicación o
utilizar una DLL o un componente viejo.

Muchas gracias por la ayuda,


Camilo Arango

On Fri, 24 Nov 2006 20:24:19 +0100, Camilo
wrote:

Mostrar la cita

Hola Zephryn;

Muchas gracias por tu respuesta; quisiera hacerte algunas mas para
complementar, si no es mucha molestia;

1. Según lo que me dices, yo podría escribir (a la antigua) un programa
con
un EXE y varios DLL's y constituir así una API también para, digamos,
facilitársela a algún tercero para que a su vez la utilice para escribir
un
programa? En ese caso, mi API sería la definición de todo lo que he
implementado para él en mi EXE y mis DLL's?

Sí, exactamente. Podrías hacer eso o un programa. De hecho, si haces una
biblioteca (si lo haces tu es mejor llamarlo biblioteca), podrías
distribuir tu DLL con tus funciones o clases agrupadas, y una serie de
ficheros .h para las definiciones si la haces en C o C++, y supongo que
sólo con la DLL bastaría para Visual Basic.

Mostrar la cita

2. No me queda muy claro que es el COM; es un modelo con el que un
programador trabaja, y va enlazando o referenciando componentes que va
necesitando a medida que va desarrollando su programa a través me imagino
del IDE, pero al final cuando compila obtiene también un EXE y unos DLL's

Más o menos sí. Luego el instalador debe copiar esos componentes, que
suelen ser fichero .OCX, aunque pueden tener otras extensiones como DLL y
registrarlos en el ordenador de destino. Aparte, claro, de los que el
propio programador ha hecho y que usa esos componentes.

Por ejemplo, el Word es una ingente cantidad de componentes COM junto a un
ejecutable y varias DLL.

Mostrar la cita

correcto? Y entonces que viene siendo las MFC (Microsoft Foundation
Classes)?

Pues otro marco de trabajo, parecido al .NET. Las MFC se basan en el API
Win32 para encapsular dichas funciones en una serie de clases más o menos
coherentes con un comportamiento algo más lógico que el Win32, que es
bastante caótico. Otra forma de ver a las MFC es como un envoltorio al
Win32 que en cierta medida pone algo de orden y permite programar en
C++ mucho más fácilmente -es un decir- que en C o C++ para Win32.

Personalmente, y digo personalmente, el .NET no es más que un marco de
trabajo mucho -y esta vez sí es mucho más- coherente para desarrollar
aplicaciones Windows (tanto Web como de escritorio), lo que ocurre es que
es muy jovencito y todavía está algo verde, pero cuando lleve la solera de
otros marcos, puede llegar a ser algo verdaderamente rompedor, hasta el
punto de que hagan chips que ejecuten el ensamblador del .NET igual que
ahora lo hacen con el "ensamblador nativo", para entendernos.

Mostrar la cita

Gracias por tu ayuda!

Saludos,

Camilo



"RFOG" escribió en el mensaje
news:
Mostrar la cita

En pocas palabras, todo lo que comentas es lo que, desde el mundo .NET
se
ha dado en llamar código antiguo u obsoleto, que realmente no lo es y
todavía siguen haciéndose miles y miles de programas bajo esas
tecnologías.

Un API es un Application Program Interface, o sea, un Interfaz para
Programación de Aplicaciones, o sea una serie de "cosas" disponibles
para
construir programas.

Win32 es el API nativo u original de Windows. Son miles y miles de
funciones disponibles para que el programador las use y construya sus
programas. Están escritas en C y C++ y son el núcleo y centro de todos
los
Windows, incluso el Vista. Esas funciones se agrupan en diferentes
ficheros, conocidos como DLLs y ejecutables.

Una DLL es un fichero que contiene un grupo de funciones o clases
empaquetados convenientemente. Digamos que es el concepto anterior a
ensamblado.

Un exe es un programa ejecutable -aunque no siempre, podría ser sólo una
DLL u otra cosa-.

Generalmente una aplicación "obsoleta" es un conjunto de DLLs, ficheros
varios y uno o más ejecutables. Es la forma tradicional de trabajar en
cualquier sistema operativo desde el principio de los tiempos (de hecho
el
propio sistema operativo no es más que eso). Aplicaciones "obsoletas"
escritas con DLLs y EXEs son el Word, el PowerPoint, el Autocad, el
Outlook (el del Office y el Express), el Explorador de Windows, el bloc
de
notas, el Visual Studio...

El "GetSystemInfo" que nombras es una función disponible en el API
Win32,
igual que hay unos cuantos miles de ellas más y que ofrece Windows a los
programadores para que las llamen. Todo eso está documentado en la MSDN
que acompaña a tu Visual Studio y en la versión OnLine:
http://msdn2.microsoft.com/en-us/li...fault.aspx

La descripción de la función está aquí:
http://msdn2.microsoft.com/en-gb/li...4381.aspx, y verás que al
final te dice en qué fichero .H se ecuentra su definición y en qué DLL
está alojada.

COM es un modelo de compomentes o de programación, igual que el NET pero
algo más antigua; la idea es tener componentes y juntarlos de forma que
todos ellos formen una aplicación. Trabajar con COM de forma nativa es
enormemente complejo, y bajo .NET se ha simplificado bastante. Parecido
a
juntar DLLs con EXEs y obtener una aplicación, pero los elementos COM
son
"inteligentes" en el sentido de que se autodescriben y ofrecen
interfaces
para su uso, digamos que es el origen de la reflexión en NET.

Y no pienses que el NET es la panacea de todas las panaceas, no es más
que
una máquina virtual que ejecuta una serie de bibliotectas de igual forma
que el Java, y tampoco se trata de una biblioteca completa, si no no
haría
falta utilizar código legado.

No dudes en preguntar más si no lo tienes claro.

Visita mi blog principal: http://rfog.blogsome.com
Y este sobre programaci?n: http://geeks.ms/blogs/rfog
Libros, ciencia ficcion y programacion
>> Hombre invisible busca mujer transparente para hacer lo nunca visto.

"Camilo" wrote in message
news:
Mostrar la cita

Saludos a todos los miembros de este grupo!

Estoy estudiando para obtener la certificación 70-305 (Desarrollar
aplicaciones web con .NET) y tengo algunas dudas conceptuales que
seguramente le serán muy fáciles de resolver a quienes tienen bastante
experiencia; mi problema es el siguiente: Cuando se habla de la
plataforma .NET, se habla de código administrado (managed code) a
través
del CLR. Sin embargo, estoy estudiando que .NET provee algunas clases
para interoperar con COM y con EXE's y APISs, DLL's heredadas. La
pregunta es: Que es exactamente (en palabras cortas) cada una de estas
cosas (COM, EXE's, API's DLL's), y en especial, enque se diferencia COM
de las DLL's o API´s heredadas? Yo entiendo que una DLL es una
librería,
y un EXE es un ejecutable, pero no entiendo que hay detrás de esto.
Tampoco de COM (que no corresponde con un tipo de archivos; lo que he
leido hablan de un modelo de programación, pero no logro aterrizar la
idea).

Por otro lado, en uno de los ejemplos que he mirado ilustran como
llamar
al procedimiento GetSystemInfo de la API "kernel32.dll". Por lo que
veo,
uno debe conocer la DLL para poder saber que métodos invocar y qué
parametros proporcionar. Como sabe uno eso? Hay un mapa o algo donde
uno
sepa cada DLL que "tiene por dentro"?

Mis dudas son simplemente conceptuales, y como soy nuevo en el mundo de
la programación no me interesa (por ahora al menos) conocer en detalle
esto del COM y amigos; simplemente quiero poder entender
conceptualmente
para cuando se presente la necesidad de integrar una aplicación o
utilizar una DLL o un componente viejo.

Muchas gracias por la ayuda,


Camilo Arango

Visita mi blog principal: http://rfog.blogsome.com
Y este sobre programaci?n: http://geeks.ms/blogs/rfog
Libros, ciencia ficcion y programacion
Hombre invisible busca mujer transparente para hacer lo nunca visto.

OK, Zephryn, muchísimas gracias!!!


"RFOG" escribió en el mensaje
news:
Mostrar la cita

On Fri, 24 Nov 2006 20:24:19 +0100, Camilo
wrote:

Mostrar la cita

Hola Zephryn;

Muchas gracias por tu respuesta; quisiera hacerte algunas mas para
complementar, si no es mucha molestia;

1. Según lo que me dices, yo podría escribir (a la antigua) un programa
con
un EXE y varios DLL's y constituir así una API también para, digamos,
facilitársela a algún tercero para que a su vez la utilice para escribir
un
programa? En ese caso, mi API sería la definición de todo lo que he
implementado para él en mi EXE y mis DLL's?

Sí, exactamente. Podrías hacer eso o un programa. De hecho, si haces una
biblioteca (si lo haces tu es mejor llamarlo biblioteca), podrías
distribuir tu DLL con tus funciones o clases agrupadas, y una serie de
ficheros .h para las definiciones si la haces en C o C++, y supongo que
sólo con la DLL bastaría para Visual Basic.

Mostrar la cita

2. No me queda muy claro que es el COM; es un modelo con el que un
programador trabaja, y va enlazando o referenciando componentes que va
necesitando a medida que va desarrollando su programa a través me imagino
del IDE, pero al final cuando compila obtiene también un EXE y unos DLL's

Más o menos sí. Luego el instalador debe copiar esos componentes, que
suelen ser fichero .OCX, aunque pueden tener otras extensiones como DLL y
registrarlos en el ordenador de destino. Aparte, claro, de los que el
propio programador ha hecho y que usa esos componentes.

Por ejemplo, el Word es una ingente cantidad de componentes COM junto a un
ejecutable y varias DLL.

Mostrar la cita

correcto? Y entonces que viene siendo las MFC (Microsoft Foundation
Classes)?

Pues otro marco de trabajo, parecido al .NET. Las MFC se basan en el API
Win32 para encapsular dichas funciones en una serie de clases más o menos
coherentes con un comportamiento algo más lógico que el Win32, que es
bastante caótico. Otra forma de ver a las MFC es como un envoltorio al
Win32 que en cierta medida pone algo de orden y permite programar en C++
mucho más fácilmente -es un decir- que en C o C++ para Win32.

Personalmente, y digo personalmente, el .NET no es más que un marco de
trabajo mucho -y esta vez sí es mucho más- coherente para desarrollar
aplicaciones Windows (tanto Web como de escritorio), lo que ocurre es que
es muy jovencito y todavía está algo verde, pero cuando lleve la solera de
otros marcos, puede llegar a ser algo verdaderamente rompedor, hasta el
punto de que hagan chips que ejecuten el ensamblador del .NET igual que
ahora lo hacen con el "ensamblador nativo", para entendernos.

Mostrar la cita

Gracias por tu ayuda!

Saludos,

Camilo



"RFOG" escribió en el mensaje
news:
Mostrar la cita

En pocas palabras, todo lo que comentas es lo que, desde el mundo .NET
se
ha dado en llamar código antiguo u obsoleto, que realmente no lo es y
todavía siguen haciéndose miles y miles de programas bajo esas
tecnologías.

Un API es un Application Program Interface, o sea, un Interfaz para
Programación de Aplicaciones, o sea una serie de "cosas" disponibles
para
construir programas.

Win32 es el API nativo u original de Windows. Son miles y miles de
funciones disponibles para que el programador las use y construya sus
programas. Están escritas en C y C++ y son el núcleo y centro de todos
los
Windows, incluso el Vista. Esas funciones se agrupan en diferentes
ficheros, conocidos como DLLs y ejecutables.

Una DLL es un fichero que contiene un grupo de funciones o clases
empaquetados convenientemente. Digamos que es el concepto anterior a
ensamblado.

Un exe es un programa ejecutable -aunque no siempre, podría ser sólo una
DLL u otra cosa-.

Generalmente una aplicación "obsoleta" es un conjunto de DLLs, ficheros
varios y uno o más ejecutables. Es la forma tradicional de trabajar en
cualquier sistema operativo desde el principio de los tiempos (de hecho
el
propio sistema operativo no es más que eso). Aplicaciones "obsoletas"
escritas con DLLs y EXEs son el Word, el PowerPoint, el Autocad, el
Outlook (el del Office y el Express), el Explorador de Windows, el bloc
de
notas, el Visual Studio...

El "GetSystemInfo" que nombras es una función disponible en el API
Win32,
igual que hay unos cuantos miles de ellas más y que ofrece Windows a los
programadores para que las llamen. Todo eso está documentado en la MSDN
que acompaña a tu Visual Studio y en la versión OnLine:
http://msdn2.microsoft.com/en-us/li...fault.aspx

La descripción de la función está aquí:
http://msdn2.microsoft.com/en-gb/li...4381.aspx, y verás que al
final te dice en qué fichero .H se ecuentra su definición y en qué DLL
está alojada.

COM es un modelo de compomentes o de programación, igual que el NET pero
algo más antigua; la idea es tener componentes y juntarlos de forma que
todos ellos formen una aplicación. Trabajar con COM de forma nativa es
enormemente complejo, y bajo .NET se ha simplificado bastante. Parecido
a
juntar DLLs con EXEs y obtener una aplicación, pero los elementos COM
son
"inteligentes" en el sentido de que se autodescriben y ofrecen
interfaces
para su uso, digamos que es el origen de la reflexión en NET.

Y no pienses que el NET es la panacea de todas las panaceas, no es más
que
una máquina virtual que ejecuta una serie de bibliotectas de igual forma
que el Java, y tampoco se trata de una biblioteca completa, si no no
haría
falta utilizar código legado.

No dudes en preguntar más si no lo tienes claro.

Visita mi blog principal: http://rfog.blogsome.com
Y este sobre programaci?n: http://geeks.ms/blogs/rfog
Libros, ciencia ficcion y programacion
>>> Hombre invisible busca mujer transparente para hacer lo nunca visto.

"Camilo" wrote in message
news:
Mostrar la cita

Saludos a todos los miembros de este grupo!

Estoy estudiando para obtener la certificación 70-305 (Desarrollar
aplicaciones web con .NET) y tengo algunas dudas conceptuales que
seguramente le serán muy fáciles de resolver a quienes tienen bastante
experiencia; mi problema es el siguiente: Cuando se habla de la
plataforma .NET, se habla de código administrado (managed code) a
través
del CLR. Sin embargo, estoy estudiando que .NET provee algunas clases
para interoperar con COM y con EXE's y APISs, DLL's heredadas. La
pregunta es: Que es exactamente (en palabras cortas) cada una de estas
cosas (COM, EXE's, API's DLL's), y en especial, enque se diferencia COM
de las DLL's o API´s heredadas? Yo entiendo que una DLL es una
librería,
y un EXE es un ejecutable, pero no entiendo que hay detrás de esto.
Tampoco de COM (que no corresponde con un tipo de archivos; lo que he
leido hablan de un modelo de programación, pero no logro aterrizar la
idea).

Por otro lado, en uno de los ejemplos que he mirado ilustran como
llamar
al procedimiento GetSystemInfo de la API "kernel32.dll". Por lo que
veo,
uno debe conocer la DLL para poder saber que métodos invocar y qué
parametros proporcionar. Como sabe uno eso? Hay un mapa o algo donde
uno
sepa cada DLL que "tiene por dentro"?

Mis dudas son simplemente conceptuales, y como soy nuevo en el mundo de
la programación no me interesa (por ahora al menos) conocer en detalle
esto del COM y amigos; simplemente quiero poder entender
conceptualmente
para cuando se presente la necesidad de integrar una aplicación o
utilizar una DLL o un componente viejo.

Muchas gracias por la ayuda,


Camilo Arango

Visita mi blog principal: http://rfog.blogsome.com
Y este sobre programaci?n: http://geeks.ms/blogs/rfog
Libros, ciencia ficcion y programacion
> Hombre invisible busca mujer transparente para hacer lo nunca visto.

;-)

On Fri, 24 Nov 2006 22:02:56 +0100, Camilo
wrote:

Mostrar la cita

OK, Zephryn, muchísimas gracias!!!


"RFOG" escribió en el mensaje
news:
Mostrar la cita

On Fri, 24 Nov 2006 20:24:19 +0100, Camilo

wrote:

Mostrar la cita

Hola Zephryn;

Muchas gracias por tu respuesta; quisiera hacerte algunas mas para
complementar, si no es mucha molestia;

1. Según lo que me dices, yo podría escribir (a la antigua) un programa
con
un EXE y varios DLL's y constituir así una API también para, digamos,
facilitársela a algún tercero para que a su vez la utilice para
escribir
un
programa? En ese caso, mi API sería la definición de todo lo que he
implementado para él en mi EXE y mis DLL's?

Sí, exactamente. Podrías hacer eso o un programa. De hecho, si haces una
biblioteca (si lo haces tu es mejor llamarlo biblioteca), podrías
distribuir tu DLL con tus funciones o clases agrupadas, y una serie de
ficheros .h para las definiciones si la haces en C o C++, y supongo que
sólo con la DLL bastaría para Visual Basic.

Mostrar la cita

2. No me queda muy claro que es el COM; es un modelo con el que un
programador trabaja, y va enlazando o referenciando componentes que va
necesitando a medida que va desarrollando su programa a través me
imagino
del IDE, pero al final cuando compila obtiene también un EXE y unos
DLL's

Más o menos sí. Luego el instalador debe copiar esos componentes, que
suelen ser fichero .OCX, aunque pueden tener otras extensiones como DLL
y
registrarlos en el ordenador de destino. Aparte, claro, de los que el
propio programador ha hecho y que usa esos componentes.

Por ejemplo, el Word es una ingente cantidad de componentes COM junto a
un
ejecutable y varias DLL.

Mostrar la cita

correcto? Y entonces que viene siendo las MFC (Microsoft Foundation
Classes)?

Pues otro marco de trabajo, parecido al .NET. Las MFC se basan en el API
Win32 para encapsular dichas funciones en una serie de clases más o
menos
coherentes con un comportamiento algo más lógico que el Win32, que es
bastante caótico. Otra forma de ver a las MFC es como un envoltorio al
Win32 que en cierta medida pone algo de orden y permite programar en
C++
mucho más fácilmente -es un decir- que en C o C++ para Win32.

Personalmente, y digo personalmente, el .NET no es más que un marco de
trabajo mucho -y esta vez sí es mucho más- coherente para desarrollar
aplicaciones Windows (tanto Web como de escritorio), lo que ocurre es
que
es muy jovencito y todavía está algo verde, pero cuando lleve la solera
de
otros marcos, puede llegar a ser algo verdaderamente rompedor, hasta el
punto de que hagan chips que ejecuten el ensamblador del .NET igual que
ahora lo hacen con el "ensamblador nativo", para entendernos.

Mostrar la cita

Gracias por tu ayuda!

Saludos,

Camilo



"RFOG" escribió en el mensaje
news:
Mostrar la cita

En pocas palabras, todo lo que comentas es lo que, desde el mundo .NET
se
ha dado en llamar código antiguo u obsoleto, que realmente no lo es y
todavía siguen haciéndose miles y miles de programas bajo esas
tecnologías.

Un API es un Application Program Interface, o sea, un Interfaz para
Programación de Aplicaciones, o sea una serie de "cosas" disponibles
para
construir programas.

Win32 es el API nativo u original de Windows. Son miles y miles de
funciones disponibles para que el programador las use y construya sus
programas. Están escritas en C y C++ y son el núcleo y centro de todos
los
Windows, incluso el Vista. Esas funciones se agrupan en diferentes
ficheros, conocidos como DLLs y ejecutables.

Una DLL es un fichero que contiene un grupo de funciones o clases
empaquetados convenientemente. Digamos que es el concepto anterior a
ensamblado.

Un exe es un programa ejecutable -aunque no siempre, podría ser sólo
una
DLL u otra cosa-.

Generalmente una aplicación "obsoleta" es un conjunto de DLLs,
ficheros
varios y uno o más ejecutables. Es la forma tradicional de trabajar en
cualquier sistema operativo desde el principio de los tiempos (de
hecho
el
propio sistema operativo no es más que eso). Aplicaciones "obsoletas"
escritas con DLLs y EXEs son el Word, el PowerPoint, el Autocad, el
Outlook (el del Office y el Express), el Explorador de Windows, el
bloc
de
notas, el Visual Studio...

El "GetSystemInfo" que nombras es una función disponible en el API
Win32,
igual que hay unos cuantos miles de ellas más y que ofrece Windows a
los
programadores para que las llamen. Todo eso está documentado en la
MSDN
que acompaña a tu Visual Studio y en la versión OnLine:
http://msdn2.microsoft.com/en-us/li...fault.aspx

La descripción de la función está aquí:
http://msdn2.microsoft.com/en-gb/li...4381.aspx, y verás que al
final te dice en qué fichero .H se ecuentra su definición y en qué DLL
está alojada.

COM es un modelo de compomentes o de programación, igual que el NET
pero
algo más antigua; la idea es tener componentes y juntarlos de forma
que
todos ellos formen una aplicación. Trabajar con COM de forma nativa es
enormemente complejo, y bajo .NET se ha simplificado bastante.
Parecido
a
juntar DLLs con EXEs y obtener una aplicación, pero los elementos COM
son
"inteligentes" en el sentido de que se autodescriben y ofrecen
interfaces
para su uso, digamos que es el origen de la reflexión en NET.

Y no pienses que el NET es la panacea de todas las panaceas, no es más
que
una máquina virtual que ejecuta una serie de bibliotectas de igual
forma
que el Java, y tampoco se trata de una biblioteca completa, si no no
haría
falta utilizar código legado.

No dudes en preguntar más si no lo tienes claro.

Visita mi blog principal: http://rfog.blogsome.com
Y este sobre programaci?n: http://geeks.ms/blogs/rfog
Libros, ciencia ficcion y programacion
>>>> Hombre invisible busca mujer transparente para hacer lo nunca visto.

"Camilo" wrote in message
news:
Mostrar la cita

Saludos a todos los miembros de este grupo!

Estoy estudiando para obtener la certificación 70-305 (Desarrollar
aplicaciones web con .NET) y tengo algunas dudas conceptuales que
seguramente le serán muy fáciles de resolver a quienes tienen
bastante
experiencia; mi problema es el siguiente: Cuando se habla de la
plataforma .NET, se habla de código administrado (managed code) a
través
del CLR. Sin embargo, estoy estudiando que .NET provee algunas clases
para interoperar con COM y con EXE's y APISs, DLL's heredadas. La
pregunta es: Que es exactamente (en palabras cortas) cada una de
estas
cosas (COM, EXE's, API's DLL's), y en especial, enque se diferencia
COM
de las DLL's o API´s heredadas? Yo entiendo que una DLL es una
librería,
y un EXE es un ejecutable, pero no entiendo que hay detrás de esto.
Tampoco de COM (que no corresponde con un tipo de archivos; lo que he
leido hablan de un modelo de programación, pero no logro aterrizar la
idea).

Por otro lado, en uno de los ejemplos que he mirado ilustran como
llamar
al procedimiento GetSystemInfo de la API "kernel32.dll". Por lo que
veo,
uno debe conocer la DLL para poder saber que métodos invocar y qué
parametros proporcionar. Como sabe uno eso? Hay un mapa o algo donde
uno
sepa cada DLL que "tiene por dentro"?

Mis dudas son simplemente conceptuales, y como soy nuevo en el mundo
de
la programación no me interesa (por ahora al menos) conocer en
detalle
esto del COM y amigos; simplemente quiero poder entender
conceptualmente
para cuando se presente la necesidad de integrar una aplicación o
utilizar una DLL o un componente viejo.

Muchas gracias por la ayuda,


Camilo Arango

Visita mi blog principal: http://rfog.blogsome.com
Y este sobre programaci?n: http://geeks.ms/blogs/rfog
Libros, ciencia ficcion y programacion
>> Hombre invisible busca mujer transparente para hacer lo nunca visto.

Visita mi blog principal: http://rfog.blogsome.com
Y este sobre programaci?n: http://geeks.ms/blogs/rfog
Libros, ciencia ficcion y programacion
Hombre invisible busca mujer transparente para hacer lo nunca visto.