Cómo identificar idénticas tarjetas de PC de 16 bits que se insertan en las ranuras de diferentes

Seleccione idioma Seleccione idioma
Id. de artículo: 323610 - Ver los productos a los que se aplica este artículo
Expandir todo | Contraer todo

En esta página

Resumen

Las aplicaciones que tienen acceso a las tarjetas de PC que tenga que identificar el mediante el uso de algunas características que pueden ser externamente percibidos, como las tarjetas la posición física que ocupan las PC cards. Esta capacidad para identificar una tarjeta es especialmente importante cuando se inserta más de una tarjeta del mismo tipo en diferentes slots. Cuando se produce esta situación, las aplicaciones tienen que indicar a el usuario final la tarjeta específica que se ejecuta una operación determinada. Por ejemplo, una aplicación puede solicitar al usuario final conectarse a una referencia externa cable a una de las tarjetas de PC que se inserta en una ranura específica.

Este artículo describe cómo identificar idénticas tarjetas de PC de 16 bits son se insertan en las ranuras de diferentes. No existe forma alguna de proporcionar esta información en forma de una ranura número o como una posición relativa (por ejemplo, "ranura superior" o "de la ranura inferior"). Sin embargo, puede recopilar información suficiente para distinguir dos idénticos las tarjetas en las ranuras de diferentes y a reconocer si una tarjeta está conectada a la ranura de mismo que ocupaba anteriormente.

Nota Aunque este artículo está destinado a la identificación de los PC de 16 bits las tarjetas, el algoritmo que se muestra más adelante en este artículo se puede aplicar a tarjetas CardBus de 32 bits con algunas medidas de simplificación (consulte en el apartado "Notas adicionales" en la sección "Más información" de este artículo).

La sección "Más información" incluye las referencias numeradas en notas al pie ([#####]) que se enumeran en la sección "Notas" al final del artículo. Para continuar leyendo el artículo después de leer la nota, haga clic en el vínculo "a".

Más información

Identificar y localizar la ranura

Buses que ofrecen información acerca de la ubicación física de un tarjeta puede proporcionar la ubicación en el campo UINumber de la estructura de datos DEVICE_CAPABILITIES . Esta estructura de datos se rellena por el bus controlador propio en respuesta al método IRP_MN_QUERY_CAPABILITIES . La presencia del campo UINumber es para que los OEM pueden identificar visualmente una ranura en la parte exterior de la caja del equipo. Por ejemplo, una etiqueta numerada puede coincidir con la información que aparece en la interfaz de usuario de Microsoft Windows. Configuración avanzada e interfaz de energía (ACPI) BIOS pueden notificar esto información al implementar el método _SUN .

Microsoft Windows XP

En Windows XP, la información desde el método _SUN , si se implementa, se pasa correctamente por el bus PCMCIA controlador. Si este método no está implementado, o si el sistema no tiene un BIOS ACPI, el valor predeterminado de 0xFFFFFFFF aparece en este campo.

Microsoft Windows 2000

En Windows 2000, el controlador de bus PCMCIA sobrescribe incorrectamente esto campo con un cero para la mayoría de los adaptadores PCMCIA (también se denomina HBAs, Host Bus Adaptadores, o controladores PCMCIA), sin tener en cuenta el real y colocar, es decir ocupada por la tarjeta de PC.

Por lo general, los equipos que admiten tarjetas de Personal Computer Memory Card International Association (PCMCIA) ofrecen dos zócalos. Sin embargo, cuatro o más sockets pueden estar disponibles en una única equipo. Dependiendo del hardware subyacente, los objetos que son dispositivos enumerados por el sistema operativo para cada adaptador PCMCIA se pueden asociar con uno o varios sockets.

Adaptadores, objetos de dispositivo y sockets

Adaptadores están en uno de estos procedimientos categorías:
  • sockets de 2 o más por cada objeto de dispositivo; objeto de 1 dispositivo por adaptador

    adaptadores PCMCIA de 16 bits que están diseñados para la tecnología móvil Intel x86 sistema operativo puede tener hasta 16 zócalos por cada adaptador. [1] Por lo general, se tiene dos zócalos. El adaptador se enumera como un objeto de dispositivo único por el sistema operativo y el adaptador controla sus tomas de dos o más. Más de 16 bits los adaptadores son de controlador de interrupción de PC Card (PCIC)-adaptadores compatibles.
  • 1 socket por cada objeto de dispositivo; 2 o más objetos de dispositivo por adaptador

    Adaptadores CardBus pueden implementar hasta ocho sockets. Por lo general, disponen de dos zócalos. El adaptador implementa un puente de PCI a CardBus de interconexión de componentes periféricos (PCI, Peripheral Component Interconnect) para cada socket y cada puente es una función independiente de PCI en el adaptador. [2]Esto significa que cada uno de estos puentes aparece en el sistema operativo como una objeto de dispositivo independiente que controla su propio socket.

    Por ejemplo, el caso habitual de un adaptador que se compone de dos puentes PCI a CardBus hace que el sistema operativo enumerar los dos objetos de dispositivo. Estos objetos representan los puentes en el adaptador; no representan el adaptador sí mismo.
Según esta clasificación, un objeto de dispositivo en el presente puede representar el contexto de un adaptador con varios sockets o un socket que pertenece a un puente de PCI a CardBus. Cuando es necesario distinguir entre estos dos casos, el principal único término o el objeto de dispositivo primario es adoptado.

Equipos que requieren más de dos sockets pueden tener más adaptadores de a bordo. Por ejemplo, podría tener un equipo de escritorio en su expansión ranuras (ISA, PCI y otros) de varias tarjetas para implementar más de un adaptador. Estos adaptadores pertenecen a una de las categorías que se mencionan anteriormente en Este artículo, posiblemente en diversas combinaciones.

Cómo identificar un socket

Por lo general, para identificar un socket, debe recopilar la siguiente información:
  • La posición de la toma de corriente en el adaptador cuando el elemento primario objeto de dispositivo posee varios sockets. Este fragmento de información se conoce como un número de socket.
  • La ubicación del elemento primario en el bus de host. Esta pieza de información es la ubicación primaria conocida como información.

Número de socket

Es el número de Socket del socket que está conectada a la tarjeta proporcionado por el controlador de bus controlando el paquete de solicitud de E/S de plug-and-play (IRP Plug and Play)IRP_MJ_PNP/IRP_MN_QUERY_CAPABILITIES. El controlador de bus llena al miembro de la dirección de la estructura DEVICE_CAPABILITIES que está asociado a este IRP.
  • La dirección se establece en 0 x 0 para las tarjetas de PC que se insertan en el primer zócalo.
  • La dirección se establece en 0 x 40 para tarjetas de PC que se insertan en el zócalo del segundo.[3]
El mismo valor está disponible para el código de modo de usuario mediante una llamada a la función SetupDiGetDeviceRegistryProperty .

Información de la ubicación principal

A recuperar la información de ubicación primario, se debe mover desde el DevNode del PC tarjeta de su elemento primario DevNode.[4] El objeto primario DevNode es en realidad el DevNode de la objeto de dispositivo primario. La propiedad LocationInformation (almacenada en el registro en la clave de hardware de dispositivo), contiene información exclusiva acerca de la ubicación física de el adaptador o el puente en el bus de host.[5]

Por ejemplo, en un CardBus adaptador con dos puentes:
  • Puente 1 tiene LocationInformation establecido en "X, el dispositivo Y, en el bus PCI function 0".
  • Puente 2 tiene LocationInformation establecido en "función de X, el dispositivo Y, en el bus PCI 1".
Para ver información similar, como se muestra en El Administrador de dispositivos, abra las propiedades de un dispositivo CardBus, haga clic en el General ficha y, a continuación, ver la información en el Ubicación campo.

En la tabla siguiente resume la información ya que se menciona en este artículo para varios casos de adaptadores. Como ha mencionado anteriormente, el informe de Windows 2000 y Windows XP UINumber diferente.

Windows XP

Contraer esta tablaAmpliar esta tabla
AdaptadorBus de hostTarjetaDirecciónUINumberInformación de la ubicación del objeto de dispositivo para padres
CardBusPCI1 º0 x 00xFFFFFFFF"PCI bus x, y de dispositivo, la función 0 "
CardBusPCI2 º0 x 00xFFFFFFFF"PCI bus x, y de dispositivo, la función 1 "
CardBus (ACPI
método _SUN
implementado)
PCI1 º0 x 00 x 0"PCI bus x, y de dispositivo, la función 0 "
CardBus (ACPI
método _SUN
implementado)
PCI2 º0 x 00 x 1"PCI bus x, y de dispositivo, la función 1 "
PCICPCI1 º0 x 00xFFFFFFFF"PCI bus x, y de dispositivo, la función 0 "
PCICPCI2 º0 x 400xFFFFFFFF"PCI bus x, y de dispositivo, la función 0 "
PCICISA1 º0 x 00xFFFFFFFFn/d
PCICISA2 º0 x 400xFFFFFFFFn/d

Windows 2000:

Contraer esta tablaAmpliar esta tabla
AdaptadorBus de hostTarjetaDirecciónUINumberInformación de la ubicación del objeto de dispositivo para padres
CardBusPCI1 º0 x 00 x 0"PCI bus x, y de dispositivo, la función 0 "
CardBusPCI2 º0 x 00 x 0"PCI bus x, y de dispositivo, la función 1 "
PCICPCI1 º0 x 00 x 0"PCI bus x, y de dispositivo, la función 0 "
PCICPCI2 º0 x 400 x 1"PCI bus x, y de dispositivo, la función 0 "
PCICISA1 º0 x 00 x 0n/d
PCICISA2 º0 x 400 x 1n/d
NotaEl bus ISA no proporciona los medios para localizar los dispositivos sobre él. No hay información de ubicación se notifica para un elemento primario en el bus ISA, como se muestra en las dos últimas filas de ambas tablas. En la condición de que hay un solo ISA adaptador en el equipo, existe información suficiente para distinguir desde otros adaptadores del bus PCI, incluidos los adaptadores de 16 bits y Adaptadores CardBus.

Obtener información detallada acerca de la parte del modo kernel

Para definir una nueva clase de interfaz de dispositivo, utilice la utilidad Guidgen.exe o la utilidad Uuidgen.exe para generar un GUID. Más adelante, coloca este GUID en un archivo de código fuente, normalmente un archivo de encabezado (. h). Para Para obtener más información acerca de cómo utilizar el GUID de controladores, consulte las sección "Referencias" sección de este artículo.

En el siguiente código de ejemplo, la interfaz de dispositivo GUID se asocia con la constante GUID_DEVICE_PCCRDNUL. Esta constante es define como sigue:
// Header file for GUID definition

// {8CE365E5-D1AA-4d72-9E09-1C8B83B34186}
DEFINE_GUID(GUID_DEVICE_PCCRDNUL,
0x8ce365e5, 0xd1aa, 0x4d72, 0x9e, 0x9, 0x1c, 0x8b, 0x83, 0xb3, 0x41, 0x86);
Importante: Para evitar las colisiones, generar un nuevo GUID que está asociado una constante significativa para cada implementación real de la resolución se proporciona en este artículo. Inclusión del archivo de encabezado Initguid.h antes de la definición de un GUID determina si el GUID se almacena en una sección de datos o si una sección de datos de otro módulo hace referencia a la definición de GUID que está vinculado al controlador.

En el código de modo de núcleo, el dispositivo definido interfaz debe registrar, habilitado y deshabilitado ya que la interfaz de dispositivo es necesaria.

Una interfaz de dispositivo está registrada mediante una llamada a la función IoRegisterDeviceInterface . Por lo general, este registro se realiza en la función AddDevice del controlador. El vínculo simbólico resultante devuelto por la interfaz el registro debe almacenarse en una cadena que es asignada por el controlador. Esto cadena normalmente se define y asigna en la extensión de dispositivos.

Archivo de encabezado para las definiciones del controlador principal

Ejemplo de código siguiente es desde el archivo de encabezado para el principal las definiciones del controlador e incluye la extensión de dispositivos.
typedef struct _MY_DEVICE_EXTENSION {
  ...
  UNICODE_STRING usSymbolicLinkInterfaceName;
  ...
} MY_DEVICE_EXTENSION, *PMY_DEVICE_EXTENSION;

Archivo de implementación de controlador

Ejemplo de código siguiente es desde el archivo de implementación del controlador (.c o .cpp).
NTSTATUS
AddDevice(
  IN PDRIVER_OBJECT DriverObject,
  IN PDEVICE_OBJECT PhysicalDeviceObject
)
{
  PMY_DEVICE_EXTENSION deviceExtension;
  ...
  deviceExstension = (PMY_DEVICE_EXTENSION) DeviceObject->DeviceExtension;
  ...
  IoRegisterDeviceInterface
  ( PhysicalDeviceObject,&GUID_DEVICE_PCCRDNUL,
    NULL,&deviceExtension->usSymbolicLinkInterfaceName
  );
...
}
La interfaz de dispositivo por lo general está habilitada durante la gestión de IRP_MN_START_DEVICE y se deshabilita durante la gestión de IRP_MN_REMOVE_DEVICE. Interfaces de dispositivos están tanto habilitadas como deshabilitadas mediante una llamada a la función IoSetDeviceInterfaceState con los parámetros adecuados. Después de que el vínculo simbólico está ya no está en uso (normalmente, después de que se ha deshabilitado la interfaz de dispositivo con una llamada a IoSetDeviceInterfaceState), se debe liberar la cadena relativa.

Archivo de implementación de controlador

Ejemplo de código siguiente es desde el archivo de implementación del controlador (.c o .cpp).
NTSTATUS
DispatchPnp (
  IN PDEVICE_OBJECT DeviceObject,
  IN PIRP Irp
)
{
  PIO_STACK_LOCATION irpStack;
  NTSTATUS status=STATUS_SUCCESS;
  PMY_DEVICE_EXTENSION deviceExtension;
  ...
  deviceExtension = (PMY_DEVICE_EXTENSION)DeviceObject->DeviceExtension;
  irpStack = IoGetCurrentIrpStackLocation(Irp);
  ...
  switch(irpStack->MinorFunction) {
  ...
    case IRP_MN_START_DEVICE:
      ...
      if(NT_SUCCESS(status)) {
        IoSetDeviceInterfaceState(&deviceExtension->usSymbolicLinkInterfaceName,TRUE);
      }
      ...
      break;
    ...
    case IRP_MN_REMOVE_DEVICE:
      ...
      IoSetDeviceInterfaceState(&deviceExtension->usSymbolicLinkInterfaceName,FALSE);
      RtlFreeUnicodeString(&deviceExtension->usSymbolicLinkInterfaceName);
      ...
      break;
    ...
  }
  ...
}

No es necesario cancelar el registro de una clase de interfaz de dispositivo. Para obtener más información obtener información acerca de las rutinas de interfaz de dispositivo y cómo controlar las interfaces de dispositivos, consulte la sección "Referencias".

Obtener información detallada acerca de la parte del modo de usuario

Dispositivos que pertenecen al controlador (es decir, dispositivos que pertenecen a la clase de interfaz de dispositivo definida anteriormente en este artículo) son enumerados en la parte del modo de usuario para crear una lista de tarjetas conectado. Esto lista se denomina un conjunto de información de dispositivo.[7]

Después de la lista de dispositivos se ha creado, el socket se lee el número para cada dispositivo. Esto se realiza mediante una llamada a la función SetupDiGetDeviceRegistryProperty con el parámetro de propiedad establecido en SPDRP_ADDRESS.

Para recopilar información de la ubicación principal, tendrá que iniciar desde una PC card Devnode. Devnodes forman un árbol que es similar a la que se muestra en el Administrador de dispositivos (cuando el Vista opción está establecida en Dispositivo de conexión). El elemento primario Devnode es realmente la Devnode que está asociado con el padre (la tarjeta PCMCIA o PCI a CardBus puente). Usted tiene que utilizar muchas funciones de SetupDi * y muchas funciones de CM_ * para la implementación completa. La función más importante es CM_Get_Parent. Esta función le permite ir desde un DevNode a su elemento primario nodo.

Entre las distintas propiedades que se almacenan en el hardware clave del registro del dispositivo para cada Devnode es la propiedadLocationInformation . Información de ubicación es única para cada dispositivo. Es imposible para que dos dispositivos del mismo tipo de bus en el mismo bus y que tiene ubicaciones de bus relativa idénticos. Esta cadena contiene suficiente información para identificar al elemento primario que está conectada a la tarjeta.

Algunos buses (de ejemplo, el bus ISA) no proporcionan ninguna información de ubicación. Como se mencionó anteriormente, si sólo uno de los adaptadores que reside en un bus que no tiene ubicación información, información suficiente todavía existe para que la identificación se hecho. Por ejemplo, si se mantiene un solo adaptador del bus ISA, es único identificado porque es el único que no tiene ubicación información.

En el caso más común de PC card o CardBus adaptadores que se hospedan en el bus PCI, se recupera una cadena con el formato siguiente:
"Bus PCI X, el dispositivo Y, Z de la función"
De nuevo, esta cadena es única en el sistema porque no hay ningún otro dispositivo no existe con el mismo triple cadena (el bus PCI, dispositivo, la función). Esta cadena puede utilizarse como un dato información para identificar el dispositivo de tarjeta de PC que está conectado a la siguiente adaptador.

En las implementaciones de PCI, la cadena en el formulario PCI" bus X, el dispositivo Y, Z de la función" puede analizarse para buscar y mostrar al usuario final del correspondiente información. En nuestro ejemplo, esto es el número de función ("función Z" en el cadena de ejemplo).

Nota "0" La función probablemente implementa el primer zócalo y la "función de 1 "que probablemente se implementa la segunda toma. Sin embargo, esto no es mandato por cualquier especificación. Además, en la mayoría de los portátiles, sockets no llevan etiqueta. Por lo tanto, desde la perspectiva del usuario final, hay ningún concepto de la primera o segundo socket; un socket superior o inferior está presente.

Con independencia de el concepto fundamental de la información que se proporciona al usuario final, es que existe una asociación entre un nombre de interfaz de dispositivo y su información de ubicación. En el nivel de aplicación, una tarjeta de PC que se conoce por este medio se puede abrir si se pasa a la función CreateFile el nombre de la interfaz de dispositivo como el nombre de archivo.[8] En este a propósito, una aplicación puede abrir el mismo dispositivo más tarde - posiblemente después de que el equipo se ha reiniciado - y, por tanto, asegúrese de que puede tener acceso a la tarjeta que ocupado esta misma posición física.

Resultado del ejemplo por los distintos controladores

En esta sección se proporciona dos ejemplos del resultado de ejemplo desde la consola aplicación:
  • Un equipo que tiene dos zócalos que se implementan un controlador de PCI CardBus.
  • Un equipo que tiene un controlador ISA PCIC con dos los sockets.
Para cada configuración, el resultado muestra la tarjeta PC card insertada en la ranura de la primera y segunda ranura. Información de identificación es siempre por parejas: información de ubicación y número de socket.

Controladora CardBus PCI

La diferencia entre la siguiente información de socket es el campo de función .
Primer zócalo
Socket Number        : 0
Parent Device ID     : PCI\VEN_104C&DEV_AC51&SUBSYS_012A1028&REV_00\4&139E449D&0&08F0
Location Information : PCI bus 2, device 1, function 0
Interface Symb. Link : \\?\pcmcia#card_manufacturer_and_model_strings#1#{8ce365e5-d1aa-4d72-9e09-1c8b83b34186}
-------------------------------------------------------------------------------

Completed successfully
Segundo socket
Socket Number        : 0
Parent Device ID     : PCI\VEN_104C&DEV_AC51&SUBSYS_012A1028&REV_00\4&139E449D&0&09F0
Location Information : PCI bus 2, device 1, function 1
Interface Symb. Link : \\?\pcmcia#card_manufacturer_and_model_strings#1#{8ce365e5-d1aa-4d72-9e09-1c8b83b34186}
-------------------------------------------------------------------------------

Completed successfully

Controlador ISA PCIC

La diferencia entre la siguiente información de socket es el campo número de socket .

Nota Cuando hay un único adaptador, Información de ubicación no disponible es un valor válido.
Primer zócalo
Socket Number        : 0
Location Information unavailable, likely adapter on ISA bus
Interface Symb. Link : \\?\pcmcia#card_manufacturer_and_model_strings#1#{8ce365e5-d1aa-4d72-9e09-1c8b83b34186}
-------------------------------------------------------------------------------

Completed successfully
Segundo socket
Socket Number        : 1
Location Information unavailable, likely adapter on ISA bus
Interface Symb. Link : \\?\pcmcia#card_manufacturer_and_model_strings#1#{8ce365e5-d1aa-4d72-9e09-1c8b83b34186}
-------------------------------------------------------------------------------

Completed successfully

Notas adicionales

Coinstalador del dispositivo

El código de ejemplo está pensado para recopilar la información de ubicación requerida en tiempo de ejecución; una aplicación real que se basa en el ejemplo se reunirá cada vez que se requiere. Sin embargo, esta técnica puede mejorarse mediante almacenar permanentemente la información en el registro junto con el otro información que está relacionada con una instancia específica de la tarjeta de PC. Puede hacer Estas tareas de forma estándar mediante la escritura de un coinstalador del dispositivo.[9]

La Coinstalador recopila la información de ubicación requerida sólo uno tiempo durante la instalación del dispositivo (mediante el uso del método que se describe en este artículo) y crea una cadena de identificación de la posición en el hardware del dispositivo registro. Una mejora adicional para los controladores que el nombre de sus objetos de dispositivo consiste en generar el nombre del objeto de dispositivo basado en la identificación información que haya sido elaborada por el coinstalador en el registro.

El dispositivo en el bus PCI

Si tiene una aplicación determinar si el dispositivo es en el bus PCI (por ejemplo, para analizar la cadena de información de ubicación con un algoritmo específico), la aplicación puede llamar a la función SetupDiGetDeviceRegistryProperty con la siguiente configuración:
  • El parámetro de la propiedad se establece en SPDRP_BUSTYPEGUID.
  • El GUID para el bus PCI se define en el archivo Wdmguid.h .
  • La constante asociada es GUID_BUS_TYPE_PCI.

tarjetas de PC de 16 bits y tarjetas CardBus de 32 bits

El principio que se describe en este artículo se aplica a ambos tarjetas de PC de 16 bits y tarjetas CardBus de 32 bits. Sin embargo, parece que la tarjeta de 32 bits el sistema operativo para que sea un dispositivo PCI normal. Este tipo de tarjeta tiene su propio información de ubicación que identifica de forma exclusiva. Por lo tanto, no es necesario para Consulte la información de la ubicación principal.

volver a resumen

Referencias

Para obtener más información acerca del uso de GUID de controladores, consulte la documentación siguiente:
Diseño de Windows DDK, arquitectura de controlador de modo de núcleo, Guía de técnicas de programación del conductor, utilizando el GUID en controladores
Para obtener más información acerca de las rutinas de interfaz de dispositivo y manejo de interfaces de dispositivos, consulte la documentación siguiente:
Referencia DDK, arquitectura de controlador de modo Kernel de Windows Las rutinas de soporte de controlador, resumen de la compatibilidad con el modo de núcleo, Plug and Play Rutinas, rutinas de interfaz de dispositivo.

Notas

Para continuar leyendo el artículo, haga clic en el vínculo "volver a".
  1. Anderson, Don. PCMCIA arquitectura del sistema: las tarjetas de PC de 16-bit. Addison Wesley Professional. 2 ND ed.. Capítulo 10, "El tarjeta de PC Host Bus Adapter", página 117, "número máximo de Sockets por HBA".
    volver a 1
  2. Anderson, Don. Sistema de CardBus Arquitectura. Addison-Wesley Canadá Ltd, de diciembre de 1995. Capítulo 17, "CardBus puente de configuración de registros", página 261, "Introducción".
    a 2
  3. Microsoft Windows Driver Development Kit (DDK), arquitectura de controlador de modo Kernel, referencia, Estructuras del sistema, descripción de las estructuras de Plug and Play, DEVICE_CAPABILITIES, de miembro Dirección.
    volver a 3
  4. Windows DDK, instalación, Guía de diseño, de dispositivo Clases de conjuntos de información de dispositivo.
    volver a 4
  5. Diseño de Windows DDK, instalación del dispositivo, guía, información general sobre la instalación de dispositivos, información sobre el controlador en el registro.
    a 5
  6. Windows DDK, instalación, Guía de diseño, de dispositivo Clases, clases de interfaz de dispositivo.
    volver a 6
  7. Windows DDK, instalación, Guía de diseño, de dispositivo Clases de conjuntos de información de dispositivo.
    volver a 7
  8. Windows DDK, instalación, referencia, de dispositivo Sección de acciones, SetupDiEnumDeviceInterfaces, de la instalación Comentarios.
    volver a 8
  9. Diseño de Windows DDK, instalación del dispositivo, guía, escribir un Coinstalador.
    Coinstalador de la muestra de tostadora, disponible en el DDK de Windows en la siguiente ruta:DDKDIR: \Src\General\Toaster\Coinstaller
    volver a 9

Propiedades

Id. de artículo: 323610 - Última revisión: viernes, 28 de junio de 2013 - Versión: 6.0
La información de este artículo se refiere a:
  • Microsoft Windows XP Driver Development Kit
Palabras clave: 
kbhowto kbmt KB323610 KbMtes
Traducción automática
IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.
Haga clic aquí para ver el artículo original (en inglés): 323610

Enviar comentarios

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com