Install custom serial port driver without removing serial.sys

Discussion in 'Windows Vista Drivers' started by Luke \(may the source be with you\), Feb 17, 2006.

  1. Yellow.

    I have developed a custom driver myser.sys for the serial ports COM1, COM2
    etc. Seems to work OK when manually installed on my development system, via
    "Hardware Manager|Update Driver|Show me a list of drivers in specific
    location" etc.

    However this results in serial.sys (orig MS driver) not being used at all.
    Therefore Hyperterminal or whatever COMs port ap will not work correctly
    with myser.sys.

    To install on a customer's machine, how do I:

    MyComAp Hyperterminal Ap etc
    | \ |
    | \ |
    | \ |
    myser.sys serial.sys
    \ /
    \ /
    COM port

    That is:
    1. Install myser.sys into the OS.
    2. Leave serial.sys alone so regular communications aps still work.
    3. In my user mode ap, OpenFile() the COM port using EITHER myser.sys or
    serial.sys.

    ?

    In user mode, I think I need to one-time install my driver (InstallShield
    job) using an inf file etc.

    In user mode in my comms ap, I know I need to attach my driver to HwID's
    0505 (serial port) but I don't know how. myser.sys somehow presents a
    unique COM port name (MYCOMx) and I'm not sure how to do this and I'm not
    sure where to go from there.

    Please be specific with function calls as the DDK doco does not directly
    address this particular case - I would have thought having multiple drivers
    for a specific piece of hardware should be more widely encountered.

    Thanks
    Luke
    may the source be with you

    PS.
    Some serial UARTs for example implement scratch-pad RAM which is not
    utilised by serial.sys, but which some driver developers might choose to
    utilise were it not for machine-to-machine compatibility issues - you still
    want to be able to fall back on serial.sys in that case.
     
    Luke \(may the source be with you\), Feb 17, 2006
    #1
    1. Advertisements

  2. 2 drivers cannot control the same hardware. If myser.sys can use serial.sys
    to control the hardware, then you can have myser.sys be a virtual com port
    driver and then open up the appropriate com port when myser.sys is opened.

    d
     
    Doron Holan [MS], Feb 18, 2006
    #2
    1. Advertisements

  3. Oh. I was under the impression that although a driver might exist for a
    piece of hardware, it did not actually own it until a call to StartDevice()
    or StartDriver() or whatever was made.
    In that case the concept of multiple drivers seemed a logical solution.

    Thanks for the strategy tip - seems I was way off course!

    Now on the virtual port thing...

    If I am not to muck with serial.sys for the benefit of my travelling wilbury
    customers who might actually one day need to use their serial port for
    something ELSE, how does a virtual port assist me in gaining true timing
    information from the physical port, when it is not actually the software
    which services the interrupt? Do I have any guarantees that my virtual
    driver recieves undelayed processing in synch with the real driver?

    Luke
    may the source be with you
     
    Luke \(may the source be with you\), Feb 18, 2006
    #3
  4. virtual com port driver ...

    We are obviously talking about a nice round disc here, having an axle in the
    center and tread on the outer circumference; permit me to term this item a
    'wheel'.

    Does anybody have a free-to-air source for this beast that they are willing
    to post?
     
    Luke \(may the source be with you\), Feb 19, 2006
    #4
  5. After thinking on this somewhat, I realised that probably my diagram was a
    little misleading:

    MyComAp Hyperterminal Ap etc
    | \ |
    | \ |
    | \ |
    myser.sys serial.sys
    \ /
    \ /
    COM port

    I do not intend that MyComAp accesses the COM port simultaneously via two
    drivers - simply that MyComAp has an option at winmain() to select with
    which driver the COM port shall be accessed for the duration of the ap.

    Does this change your answer?

    It is my understandanding that each driver presents a different device:
    serial.sys --> COMx
    myser.sys --> MYCOMx.

    Then the OpenFile() simply opens the relevent device (COMx or MYCOMx),
    supplying a handle.

    I'm not sure that a virtual serial port is the real answer in this
    application because I want control in the interupt handler to generate my
    accurate timing control.

    Kindly show me the light

    Luke
    may the source be with you
     
    Luke \(may the source be with you\), Feb 19, 2006
    #5
  6. it doesn't change the answer. you cannot determine which driver controls hw
    based on the app which opens it. What i would suggest is that myser.sys
    supports the serial interface (IOCTLs, etc) and that the interface between
    myser.sys and MyComAp is not the defined serial interface,which means no
    win32 COMM APIs, but a custom interface. this way myser.sys can service
    both interfaces and existing com port apps work as well as your custom ap

    d

    --
    Please do not send e-mail directly to this alias. this alias is for
    newsgroup purposes only.
    This posting is provided "AS IS" with no warranties, and confers no rights.
     
    Doron Holan [MS], Feb 20, 2006
    #6
  7. goodness gracious
    I think I'll just hijack the user's serial.sys.

    BTW, does Devcon do a temporary install, or complete install - could devcon
    be used to switch between myser.sys and serial.sys without shutting down?

    ie. Ap calls devcon to setup for myser.sys, and on ap exit calls devcon to
    reinstate serial.sys?

    Luke
    may the source be with you
     
    Luke \(may the source be with you\), Feb 20, 2006
    #7
  8. that can work as well...but what happens if your app crashes and does not
    undo the driver change? you could have a monitor app which does the change,
    launches your app, and then undos the change after your app exits.

    d

    --
    Please do not send e-mail directly to this alias. this alias is for
    newsgroup purposes only.
    This posting is provided "AS IS" with no warranties, and confers no rights.
     
    Doron Holan [MS], Feb 20, 2006
    #8
  9. MY App?
    Crashes?

    Windows fault.

    ; )

     
    Luke \(may the source be with you\), Feb 20, 2006
    #9
  10. Luke \(may the source be with you\)

    Chris Doré Guest

    What is so hard about supporting the serial interface? The serial driver
    source is in the DDK, just add to it whatever your app needs.


    Chris
     
    Chris Doré, Feb 20, 2006
    #10
  11. Eventually I considered that an extra IOCTL function might do the trick.

    In a real-world way it means I can quickly solve the problem and move
    forward.

    In serial.sys IOCTL functions are #defined for values 1 through 39
    inclusive, and serenum.sys IOCLTLs are #define-reserved for 128-256.

    So I use the DDK source and wallah insert IOCTL #40 - MY_IOCTL. At the
    SerialIoControl() IOCTL function switch, I write a tiny snippet for the case
    MY_IOCTL, which recongises my App's 'calling sign' and turns on a back door
    for serial.sys which is serviced by my App. Naturally, if MyApp does not
    service the backdoor for some time, original "serial.sys" functionality is
    automatically restored in the driver.

    serial.sys is replaced with myser.sys and users percieve no change in the
    operation of their serial port when using other Apps. This is great unless
    some other incompetent DDK developer (like me) incepts a similar solution
    and needs to overwrite myser.sys. Or by some freaky accident the backdoor I
    wrote is validated by some third-party App.

    Are there any other caveats to this approach?
    Instead of choosing #40, should I have started at the other end... #127?.

    See my recent post in newsgroup microsoft.development.device.driver.docs
    regarding lack of documentation which exemplifies real-world scenarios and
    leaves the DDK developer to weave their own poor-quality schemes.

    Only through several days of association with this news group did I get an
    actual 'guidance' response in real world terms - thanks Doran.

    Even then I am way overdue on this and am settling for the low-quality
    solution.
     
    Luke \(may the source be with you\), Feb 20, 2006
    #11
  12. Great idea Chris

    So then I end up with my serial port driver, and Window's serial port
    driver.

    Bzzzz

    Only one can be installed at any time, and the operation of mine renders the
    driver incompatible with any serial port Apps but my own.

    Not too hard at all to write the driver - no - easy in fact.

    But how to properly integrate into Windows? Ahhh yes, now here is where one
    needs (because of a lack of 'real world' DDK documentation, which is
    presented solely in referential mumbo-jumbo, and beautifully so) to have the
    experience of writing and deploying device drivers since the days of Win98.

    An attribute I dare say neither of us possesses.
     
    Luke \(may the source be with you\), Feb 20, 2006
    #12
  13. Luke \(may the source be with you\)

    Chris Doré Guest

    Then you broke the driver, fix it.
    Write an INF for your driver.


    Now the question is; What did you change in the standard serial driver to
    cause it to not work with other apps?

    Alternatively, can you do what you need using a filter driver (like
    serenum)?


    Regards, Chris

    P.S. Don't bother complaining about the docs here, you've accomplished that
    in ms.pub.dev.device.drivers.docs.
     
    Chris Doré, Feb 21, 2006
    #13
  14. The simplest way I could see to extract sub-millisecond timing information
    from the serial port is to use the existing user API call. The serial.sys
    driver is simply modified to insert timing information (3 chars should you
    ask) with each char recieved. My App knows what to do with info taken from
    Read().

    You can see that other serial Apps won't find this too helpful.

    So my serial.sys is specially modified to only invoke this mode after
    special IOCTL handshakies with my App.

    But this approach, although not pretty, works, and has done in the shortest
    possible time, and I have struggled to learn how it might otherwise be done
    elegantly, without writing my own user API calls.

    I used my .INF file to install myser.sys, which annoyingly requires system
    reboot. By 'properly integrate into Windows' I mean ensure that the
    regular serial-port user experience is never compromised by my dodgy driver.

    The only 'elegant' solution I've heard was alluded to by Doran (20 Feb). An
    intermediary driver which handles serial.sys IOCTLs and is called on by my
    own custom user API calls - too much work.

    Luke
    may the source be with you
     
    Luke \(may the source be with you\), Feb 21, 2006
    #14
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.