Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Will NT 4.0 PCMCIA driver run on Win2k

OSR_Community_UserOSR_Community_User Member Posts: 110,217
Will a driver written for NT 4.0, using PCMCIA, work on Win2k? Does PCMCIA.sys still exist? Does it read the registry and configure slots as before?

Larry

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > Will a driver written for NT 4.0, using PCMCIA, work on Win2k? Does
    > PCMCIA.sys still exist? Does it read the registry and configure slots as
    > before?

    You need no knowlege about registry and configuration slots. A pcmcia driver
    is a normal WDM driver and loaded/unload in normal PnP way.

    You can use the PCI example from Driver::Works to write a new frame for this
    driver.

    mathias
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    >Will a driver written for NT 4.0, using PCMCIA, work on Win2k? Does
    PCMCIA.sys still exist? >Does it read the registry and configure slots as
    before?

    I believe that's a no, as W2K PCMCIA drivers are PnP WDM drivers. Your
    driver get's it's resource info and insertion notification via PnP IRP's.
    Also note this driver architecture is different than the card services
    interface in the PCMCIA specs (from a third party) .

    I happen to be working on a W2K PCMCIA function driver, and have found
    PCMCIA.SYS a bit on the buggy side. Two examples, the physical slot number
    is not correctly returned (accessed via IoGetDeviceProperty) and if you try
    to read/write attribute/common memory using IRP's to the bus driver, errors
    occur if your request will cross a 4K boundary. I have found no work around
    for this first problem, even the Microsoft UI reports cards are always in
    slot 0. The second one can be worked around by chopping the request into
    smaller chunks that carefully don't span 4K offsets. I've also had zero
    success trying to get no memory window resources assign to my card. It
    should be possible to do all accesses through bus driver IRP's, which in
    theory should allow my function driver to function identically on direct
    PCIC/CardBus, USB, or SCSI attached PCMCIA slots (also assuming the
    developer of these alternative bus attached PCMCIA slot devices correctly
    implements a bus driver interface).

    Originally, I started to port a NT 4 PCMCIA driver using CardWare to W2K.
    Eventually, I found taking a working W2K PnP WDM shell, and inserting my
    device specific functionality was a LOT easier.

    - Jan
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Thanks for the insight.

    Larry
    ----- Original Message -----
    From: Jan Bottorff <[email protected]>
    To: NT Developers Interest List <[email protected]>
    Sent: Wednesday, June 07, 2000 11:52 AM
    Subject: [ntdev] Re: Will NT 4.0 PCMCIA driver run on Win2k


    > >Will a driver written for NT 4.0, using PCMCIA, work on Win2k? Does
    > PCMCIA.sys still exist? >Does it read the registry and configure slots as
    > before?
    >
    > I believe that's a no, as W2K PCMCIA drivers are PnP WDM drivers. Your
    > driver get's it's resource info and insertion notification via PnP IRP's.
    > Also note this driver architecture is different than the card services
    > interface in the PCMCIA specs (from a third party) .
    >
    > I happen to be working on a W2K PCMCIA function driver, and have found
    > PCMCIA.SYS a bit on the buggy side. Two examples, the physical slot number
    > is not correctly returned (accessed via IoGetDeviceProperty) and if you
    try
    > to read/write attribute/common memory using IRP's to the bus driver,
    errors
    > occur if your request will cross a 4K boundary. I have found no work
    around
    > for this first problem, even the Microsoft UI reports cards are always in
    > slot 0. The second one can be worked around by chopping the request into
    > smaller chunks that carefully don't span 4K offsets. I've also had zero
    > success trying to get no memory window resources assign to my card. It
    > should be possible to do all accesses through bus driver IRP's, which in
    > theory should allow my function driver to function identically on direct
    > PCIC/CardBus, USB, or SCSI attached PCMCIA slots (also assuming the
    > developer of these alternative bus attached PCMCIA slot devices correctly
    > implements a bus driver interface).
    >
    > Originally, I started to port a NT 4 PCMCIA driver using CardWare to W2K.
    > Eventually, I found taking a working W2K PnP WDM shell, and inserting my
    > device specific functionality was a LOT easier.
    >
    > - Jan
    >
    >
    >
    > ---
    > You are currently subscribed to ntdev as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    While a driver for a conform PCI-device works well under NT4.0 and W2K,
    ignored all the new PnP features of W2K because WinNT4.0 supports
    PCI-bus-device, a driver for a PCMCIA device does not. The reason for this
    can be found in the poor support for PCMCIA interface of NT4.0

    WinNT4.0 supports only intel-82365-compatible and some other standard PCMCIA
    controllers (host adapter).
    All the docu. of MS about this support are underdocumented in the Q170084
    and Q168303.

    If all the specifications under Q170084 and Q168303 of MS works well on your
    PC then all the resources assigned to the PCMCIA-device can be used after
    reading from the registry under HKLM/Hardware/Description/System/PCMCIA
    PCCARDs.

    If you do not see this golden entry as described above then WinNT4.0 does
    NOT supports the PCMCIA controller on your machine or there is some resource
    conflict.

    W2K, as Jan Bottorff said, supports PCMCIA via PnP IRPs as under Win95/98.
    So the PCMCIA driver for NT4.0 and W2k are not of the same infrastructure.

    Driver::Works or Development Kit of Cardware can not help you for 100%
    compatibility because Driver::Works does the same as I decribed above.
    Development Kit of Cardware supplies you an API interface to Cardware's Card
    Service, i.e. your driver is only Cardware compatible and you know under W2K
    you do not need any Cardware's Card Service.


    HUU DUNG NGUYEN


    > ----------
    > From: Larry Harmon[SMTP:[email protected]]
    > Reply To: NT Developers Interest List
    > Sent: Wednesday, June 07, 2000 11:41 PM
    > To: NT Developers Interest List
    > Subject: [ntdev] Re: Will NT 4.0 PCMCIA driver run on Win2k
    >
    > Thanks for the insight.
    >
    > Larry
    > ----- Original Message -----
    > From: Jan Bottorff <[email protected]>
    > To: NT Developers Interest List <[email protected]>
    > Sent: Wednesday, June 07, 2000 11:52 AM
    > Subject: [ntdev] Re: Will NT 4.0 PCMCIA driver run on Win2k
    >
    >
    > > >Will a driver written for NT 4.0, using PCMCIA, work on Win2k? Does
    > > PCMCIA.sys still exist? >Does it read the registry and configure slots
    > as
    > > before?
    > >
    > > I believe that's a no, as W2K PCMCIA drivers are PnP WDM drivers. Your
    > > driver get's it's resource info and insertion notification via PnP
    > IRP's.
    > > Also note this driver architecture is different than the card services
    > > interface in the PCMCIA specs (from a third party) .
    > >
    > > I happen to be working on a W2K PCMCIA function driver, and have found
    > > PCMCIA.SYS a bit on the buggy side. Two examples, the physical slot
    > number
    > > is not correctly returned (accessed via IoGetDeviceProperty) and if you
    > try
    > > to read/write attribute/common memory using IRP's to the bus driver,
    > errors
    > > occur if your request will cross a 4K boundary. I have found no work
    > around
    > > for this first problem, even the Microsoft UI reports cards are always
    > in
    > > slot 0. The second one can be worked around by chopping the request into
    > > smaller chunks that carefully don't span 4K offsets. I've also had zero
    > > success trying to get no memory window resources assign to my card. It
    > > should be possible to do all accesses through bus driver IRP's, which in
    > > theory should allow my function driver to function identically on direct
    > > PCIC/CardBus, USB, or SCSI attached PCMCIA slots (also assuming the
    > > developer of these alternative bus attached PCMCIA slot devices
    > correctly
    > > implements a bus driver interface).
    > >
    > > Originally, I started to port a NT 4 PCMCIA driver using CardWare to
    > W2K.
    > > Eventually, I found taking a working W2K PnP WDM shell, and inserting my
    > > device specific functionality was a LOT easier.
    > >
    > > - Jan
    > >
    > >
    > >
    > > ---
    > > You are currently subscribed to ntdev as: [email protected]
    > > To unsubscribe send a blank email to $subst('Email.Unsub')
    > >
    >
    >
    > ---
    > You are currently subscribed to ntdev as: [email protected]
    > To unsubscribe send a blank email to $subst('Email.Unsub')
    >
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 13-17 May 2024 Live, Online
Developing Minifilters 1-5 Apr 2024 Live, Online
Internals & Software Drivers 11-15 Mar 2024 Live, Online
Writing WDF Drivers 20-24 May 2024 Live, Online