home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / windows / programming / vcomm next >
Encoding:
Text File  |  1996-09-15  |  48.2 KB  |  1,297 lines

  1. Newsgroups: comp.os.ms-windows.programmer.vxd,comp.answers,news.answers
  2. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news.media.mit.edu!uhog.mit.edu!nntp.uac.net!cancer.vividnet.com!hunter.premier.net!www.nntp.primenet.com!nntp.primenet.com!news-peer.gsl.net!news.gsl.net!news.mathworks.com!newsfeed.internetmci.com!nntp-hub2.barrnet.net!nntp-hub3.barrnet.net!voder!nsc!desktop!nelson
  3. From: nelson@desktop.nsc.com (Taed Nelson)
  4. Subject: VCOMM Frequently Asked Questions (FAQ)
  5. Message-ID: <Dxp3BD.Et4@nsc.nsc.com>
  6. Followup-To: comp.os.ms-windows.programmer.vxd
  7. Summary: Common topics about VCOMM port drivers for Microsoft Windows.
  8. Sender: nelson@desktop (Taed Nelson)
  9. Nntp-Posting-Host: desktop.nsc.com
  10. Organization: National Semiconductor Corporation (Santa Clara CA USA)
  11. X-Newsreader: xrn 8.02-beta-2
  12. Date: Fri, 13 Sep 1996 23:45:13 GMT
  13. Approved: news-answers-request@MIT.EDU
  14. Lines: 1280
  15. Xref: senator-bedfellow.mit.edu comp.os.ms-windows.programmer.vxd:5582 comp.answers:21124 news.answers:81649
  16.  
  17. Archive-name: windows/programming/vcomm
  18. Posting-Frequency: bimonthly
  19. Last-modified: 1996/09/13
  20. Version: 1.8
  21.  
  22.  
  23.             ======================================
  24.             VCOMM Frequently Asked Questions (FAQ)
  25.             ======================================
  26.  
  27.  
  28.  
  29. ===================
  30. 1:  Version History
  31. ===================
  32.  
  33. Version     When    Major Changes
  34. -------    ------    -------------
  35. 1.8    960913    First official posting to comp.answers newsgroup.
  36.         Solved serial.vxd compiliation.
  37.         New HyperTerminal section.
  38. 1.7    960828    Added disclaimer.
  39. 1.6    960826    Added some more references.
  40.         Added VCOMM RxCallback register save bug.
  41.         Added something on support for DOS applications.
  42. 1.5    960711    Updated for fixes in Vireo VtoolsD 2.03.
  43.         Added Modems | More Info... AT set requirements.
  44.         Added Modems | More Info... VtoolsD PortOpen bug.
  45. 1.4    960425    Added VtoolsD contention problem.
  46.         Added blockable functions and HyperTerminal no buffers.
  47.         Added contributors' names.
  48.         More on dwLastError.
  49.         Modifications for April 1996 MSDN.
  50. 1.3    960328    Added non-standard ports, PPP, and monitoring data traffic.
  51.         Added HyperTerminal log, illegal baud rate indexes, and zmodem.
  52.         Changed CommTimeouts.
  53.         Updated for Vireo VtoolsD version 2.02.
  54. 1.2    960220    Added virtual modem, HyperTerminal, and VtoolsD makefiles.
  55. 1.1    960213    Added Table of Contents.
  56. 1.0    960208    Initial release.
  57.  
  58.  
  59.  
  60. ===========
  61. 2:  General
  62. ===========
  63.  
  64. This document attempts to capture many of the issues that come up on the VCOMM
  65. mailing list, and problems that we have found during development.  Any
  66. suggested changes should be directed to that mailing list.  (See below for
  67. information on subscribing to the mailing list.)
  68.  
  69. All topics herein should refer to the newest major version of the appropriate
  70. documentation, source, or software.  Exceptions are noted.
  71.  
  72. Many, perhaps all, of the errors mentioned in this document have been reported
  73. to the appropriate company, and may be fixed in subsequent releases.  Once
  74. they have been confirmed to be fixed, they will be removed from this document
  75. (or otherwise noted), unless there are backwards compatibility issues.
  76.  
  77. The newest version of this document can be obtained by sending a message body
  78. of "get vcomm vcomm.faq" to majordomo@corp.nsc.com, which is the server for
  79. the VCOMM mailing list.
  80.  
  81. The VCOMM mailing list also maintains an archive of postings.  Searching the
  82. archives for other topics is encouraged.
  83.  
  84.  
  85.  
  86. ===========
  87. 3:  Authors
  88. ===========
  89.  
  90. This document is made up of input from a number of people, most of whom are on
  91. the VCOMM mailing list.  Many sections are marked with the name of the
  92. contributors.  Sections which are not credited were probably written by the
  93. editor, based on information from the mailing list.  The major authors are
  94. listed below alphabetically:
  95.  
  96.     Michael Grabelkovsky, Smart Link Limited (michael@slink.co.il).
  97.  
  98.     Taed Nelson, National Semiconductor Corporation (nelson@lan.nsc.com).
  99.  
  100. The editor of this document is Taed Nelson (nelson@lan.nsc.com).
  101.  
  102.  
  103.  
  104. ============================
  105. 4:  Copyright and Disclaimer
  106. ============================
  107.  
  108. This document is Copyright 1996 by Taed Nelson and National Semiconductor
  109. Corporation.  All rights are reserved.
  110.  
  111. This document may be distributed in electronic form only, provided that no fee
  112. is charged and the document is distributed completely and exactly.  Any
  113. additions or corrections must be noted as such, and must be submitted to the
  114. editor listed above for potential future inclusion in this document.
  115.  
  116. Any other distribution or publication of this document must receive written
  117. permission from the editor, who in turn will discuss the matter with the major
  118. authors.
  119.  
  120. The information provided herein is for informational purposes only, and no
  121. warranty is either expressed or implied.
  122.  
  123.  
  124.  
  125. =====================
  126. 5:  Table of Contents
  127. =====================
  128.  
  129.     1:  Version History
  130.     2:  General
  131.     3:  Authors
  132.     4:  Copyright and Disclaimer
  133.     5:  Table of Contents
  134.     6:  Tools and Information Sources
  135.         6.1:  Microsoft
  136.         6.2:  Online
  137.         6.3:  Printed
  138.         6.4:  Software Tools
  139.         6.5:  Other
  140.     7:  General Issues
  141.         7.1:  Serial.vxd Source Won't Compile
  142.             7.1.1:  Yes, it will
  143.             7.1.2:  You need MASM Version 6.11c
  144.             7.1.3:  Minor typographical error
  145.         7.2:  Port.inf file
  146.             7.2.1:  InfEdit.exe
  147.         7.3:  Non-Standard Ports
  148.         7.4:  No Logical Resources
  149.         7.5:  Logical Memory Resources
  150.         7.6:  Init Order
  151.         7.7:  Virtual Modems and Printers
  152.         7.8:  Point-to-Point Protocol (PPP)
  153.         7.9:  How to Monitor or Intercept COMM Data Traffic
  154.         7.10:  HyperTerminal Function Trace
  155.         7.11:  Blockable Functions
  156.             7.11.1:  Blockable Port functions
  157.             7.11.2:  Non-Blockable Port functions
  158.         7.12:  Support for DOS Applications
  159.     8:  Problems With Applications
  160.         8.1:  HyperTerminal Closes the Port Unexpectedly
  161.         8.2:  HyperTerminal Zmodem Protocol Fails
  162.         8.3:  HyperTerminal Allocates No Buffers
  163.         8.4:  HyperTerminal can't work at high DTE speed
  164.         8.5:  Control Panel | Modems | More Info...
  165.     9:  Problems with VCOMM
  166.         9.1:  PortOpen Causes VCOMM to Crash
  167.         9.2:  Illegal Baud Rate Indexes
  168.         9.3:  RxCallback does not preserve EBX.
  169.     10:  Documentation Issues
  170.         10.1:  CommNotifyProc
  171.         10.2:  CommTimeouts
  172.         10.3:  PortEscapeFunction
  173.         10.4:  PortGetCommConfig and PortSetCommConfig
  174.         10.5:  PortGetEventMask
  175.         10.6:  PortGetWin32Error
  176.         10.7:  PortSetModemStatusShadow
  177.         10.8:  VCOMM_Map_Win32DCB_To_Ring0 and VCOMM_Map_Ring0DCB_To_Win32
  178.         10.9:  _PortData Structure
  179.             10.9.1:  Notification fields
  180.             10.9.2:  dwLastReceivedTime
  181.             10.9.3:  dwLastError
  182.         10.10:  Other Structures
  183.             10.10.1:  General
  184.             10.10.2:  _COMM_CONFIG
  185.         10.11:  Terminology
  186.             10.11.1:  RLSD
  187.     11:  VtoolsD Vcomm Class
  188.         11.1:  General
  189.         11.2:  Documentation Errors
  190.         11.3:  PortOpen Errors
  191.         11.4:  Contention Management Errors
  192.         11.5:  Other Errors
  193.         11.6:  Makefiles and #defines
  194.             11.6.1:  Turning off optimization (Taed's way)
  195.             11.6.2:  Turning off optimization (Michael's way)
  196.             11.6.3:  Version resource
  197.             11.6.4:  Dependencies
  198.             11.6.5:  Assert versus ASSERT
  199.             11.6.6:  DEBUG versus _DEBUG
  200.             11.6.7:  Avoiding the dprintf() call
  201.  
  202.  
  203.  
  204. =================================
  205. 6:  Tools and Information Sources
  206. =================================
  207.  
  208.  
  209. 6.1:  Microsoft
  210. ===============
  211.  
  212. Microsoft Developer Network Device Driver Kit (MSDN DDK), July 1996.
  213.  
  214. "Communications Device Drivers" (\DDK\Docs\Desguide\Comm.doc), also known as
  215. the Vcomm documentation.  In addition to the change of file name, this
  216. document changed significantly on the April 1996 DDK.  (A copy of this file,
  217. but not necessarily the newest, can also be obtain by sending a message body
  218. of "get vcomm comm.doc.uu" to majordomo@corp.nsc.com.)
  219.  
  220. Serial.vxd Source Code (\DDK\Comm\Samples\Serial\*.*).  This is (or seems to
  221. be) the source code for the Serial.vxd port driver.
  222.  
  223. Microsoft Developer Network Software Development Kit (MSDN SDK), January 1996.
  224.  
  225.  
  226. 6.2:  Online
  227. ============
  228.  
  229. VCOMM Mailing List (vcomm@corp.nsc.com).  This covers VCOMM port driver
  230. development and related issues.  The mailing list maintains an FAQ (this
  231. document that you are reading) and archives of previous messages.  Mail the
  232. body "subscribe vcomm" to majordomo@corp.nsc.com to subscribe, or contact
  233. owner-vcomm@corp.nsc.com for other requests.  (Note that the mailing list will
  234. be moving in late September 1996 (or may have already by the time you read
  235. this), but don't let that stop you from subscribing, since all addresses will
  236. be forwarded to the new site.)
  237.  
  238. DDK-L Mailing List (ddk-l@eva.dc.lsoft.com).  This covers general VxD
  239. development.  There is a $15 annual fee, but it is well worth it for the
  240. quality of the postings and subscribers.  The mailing list maintains an archiv
  241. of previous messages.  Contact listserv@peach.ease.lsoft.com to subscribe, or
  242. owner-ddk-l@chsw.com for other requests.
  243.  
  244. DDK Mailing List (ddk@cfn.ist.utl.pt).  This covers general VxD development.
  245. Mail the body "subscribe vcomm" to majordomo@cfn.ist.utl.pt to
  246. subscribe, or contact owner-vcomm@cfn.ist.utl.pt for other requests.
  247.  
  248. Comp.os.ms-windows.programmer.vxd UseNet Newsgroup.  This covers general VxD
  249. development.  There is also an FAQ for that newsgroup.
  250.  
  251.  
  252. 6.3:  Printed
  253. =============
  254.  
  255. _Systems Programming for Windows 95_, by Walter Oney.  This has an entire
  256. chapter on communications drivers, and presents a port driver written in C.
  257.  
  258.  
  259. 6.4:  Software Tools
  260. ====================
  261.  
  262. VtoolsD by Vireo Software, Version 2.03.  This contains a Vcomm port driver
  263. class, and allows one to write VxDs in C or C++.  They have a WWW page at
  264. http://world.std.com/~vireo/.
  265.  
  266. VXDMON by Mark Russinovich and Bryce Cogswell.  This program uses the
  267. Pentium's cycle counter to provide performance and control-flow information
  268. and any and all exported Virtual Machine Monitor (VMM) and Virtual Device
  269. Driver (VxD) services under Windows 95.  Available at
  270. ftp://ftp.ora.com/pub/examples/windows/win95.update/vxdmon.html.
  271.  
  272.  
  273. 6.5:  Other
  274. ===========
  275.  
  276. "Hayes AT Command Reference for OPTIMA and ACCURA Products", Hayes
  277. Microcomputer Products, Inc.  This covers the AT command set in great detail.
  278. This document can be found at ftp://ftp.hayes.com/.
  279.  
  280.  
  281.  
  282. ==================
  283. 7:  General Issues
  284. ==================
  285.  
  286.  
  287. 7.1:  Serial.vxd Source Won't Compile
  288. =====================================
  289.  
  290. [Contributed by Taed Nelson (nelson@lan.nsc.com).]
  291.  
  292. The "-coff -DBLD_COFF" must be removed from AFLAGS to get it to compile
  293. successfully.  It can be gotten to compile in other ways, but then it won't
  294. link or run correctly.
  295.  
  296. The new linker must also be used, but it will give a few warnings.  The size
  297. is also considerable smaller than the actual Serial.vxd (11K versus 18K).  The
  298. resulting VxD seems to run correctly, though.
  299.  
  300. 7.1.1:  Yes, it will
  301. --------------------
  302.  
  303. [Contributed by Bill Stuart (billstu@microsoft.com).]
  304.  
  305. I can build the serial sample without editing the makefile.  I build on Win95
  306. in a DOS box and set my environment by running:
  307.  
  308.     d:\masm611\binr\new-vars.bat
  309.     d:\mstools\setenv d:\mstools d:\msvc20\bin
  310.     d:\ddk\ddkenv 32 comm
  311.  
  312. I also place the linker I want to use in d:\ddk\bin.
  313.  
  314. 7.1.2:  You need MASM Version 6.11c
  315. -----------------------------------
  316.  
  317. The problem seems to be that it won't work with MASM version 6.11.  The update
  318. to 6.11c is allegedly on the Microsoft web site somewhere.
  319.  
  320. 7.1.3:  Minor typographical error
  321. ---------------------------------
  322.  
  323. [Contributed by Michael Grabelkovsky (michael@slink.co.il).]
  324.  
  325. A coding error that seems to compile correctly anyway is in serutil.asm.  In
  326. the function KickTx, the reference to [esi.pData.QOutMod] should just be
  327. [esi.QOutMod].
  328.  
  329.  
  330. 7.2:  Port.inf file
  331. ===================
  332.  
  333. The Vcomm document mentions a commented sample port INF file in the \DDK\Comm
  334. directory, but no such file exists.
  335.  
  336. There is a reasonable example file called \Windows95\Inf\msports.inf.  Other
  337. examples can be found in the VCOMM mailing list archives.
  338.  
  339. 7.2.1:  InfEdit.exe
  340. -------------------
  341.  
  342. [Contributed by Taed Nelson (nelson@lan.nsc.com).]
  343.  
  344. Beware when editing a port INF file with the SDK tool InfEdit.exe.  It will
  345. remove double-quote marks that are needed to do things such as:
  346. HKR,,EnumPropPages,0,"serialui.dll,EnumPropPages".
  347.  
  348.  
  349. 7.3:  Non-Standard Ports
  350. ========================
  351.  
  352. [Contributed by Taed Nelson (nelson@lan.nsc.com).]
  353.  
  354. Port drivers with non-standard logical resources will be assigned to port COM5
  355. or above.  These are typically referred to as "non-standard ports."
  356. Nonetheless, they are supported just fine by any decent Win16 or Win32
  357. application.
  358.  
  359. On non-standard ports, the port.inf file should not specify a "Contention"
  360. resource.  By default, VCOMM will perform contention management between Win16
  361. and Win32 applications.  (I have found that you can actually use *VCD when
  362. using Windows 3.11 style contention management (although I doubt it actually
  363. does contention management), but that it will not work when using with Windows
  364. 95 style.)
  365.  
  366.  
  367. 7.4:  No Logical Resources
  368. ==========================
  369.  
  370. [Contributed by Taed Nelson (nelson@lan.nsc.com).]
  371.  
  372. It is reasonable for a VCOMM port driver to have no logical configuration
  373. resources at all.  This can occur since the port driver may communicate with
  374. another driver, such as a network driver, to virtualize that as a COM port.
  375. The port driver would then have no resources of its own.
  376.  
  377. But this leads to a problem.  The documentation states (in the VCOMM Device
  378. Initialization section), "[VCOMM] assigns a PortName to the device in its
  379. hardware key, if its devnode contains system resources."  Thus, without
  380. resources, we don't get a port name, such as COM5.  And without a port name,
  381. we have discovered, we are not recognized by Dial-Up Networking or UNIMODEM.
  382. These are all required functionalities for any port driver.
  383.  
  384. The only solution at this point is to edit the Registry and add PortName and
  385. FriendlyName entries by hand.  It is possible to hard-code the PortName and
  386. FriendlyName (but not Description) in the port.inf file so that no
  387. hand-editing is required.  The place to do the editing is
  388. MyComputer\HKEY_LOCAL_MACHINE\Enum\Root\Ports\0000.
  389.  
  390.  
  391. 7.5:  Logical Memory Resources
  392. ==============================
  393.  
  394. [Contributed by David McCullough (davidm@stallion.com).]
  395.  
  396. VCOMM does not enumerate the PortNames if your device has any logical memory
  397. resources.  IO and IRQ resources are OK.
  398.  
  399. I will try to double check this again, to be sure, but my ports were
  400. enumerated fine until I added a memory address to the LogConfig, and then it
  401. stopped.
  402.  
  403. I don't know about multiple IO addresses yet.
  404.  
  405.  
  406. 7.6:  Init Order
  407. ================
  408.  
  409. [Contributed by Taed Nelson (nelson@lan.nsc.com).]
  410.  
  411. What is the proper device init order for a VCOMM port driver?  The
  412. documentation says to use UNDEFINED_INIT_ORDER, but SERIAL.VXD uses
  413. VCD_INIT_ORDER.  And in VMM.H, there is a PORT_INIT_ORDER defined, which is
  414. just slightly less than VCD.  Which is right?
  415.  
  416. This is an issue for any static port driver under Windows 95, and maybe every
  417. port driver for Windows for Workgroups.
  418.  
  419.  
  420. 7.7:  Virtual Modems and Printers
  421. =================================
  422.  
  423. [Contributed by Taed Nelson (nelson@lan.nsc.com).]
  424.  
  425. In some cases (particularly if there are no logical resources), the port
  426. driver will not actually attach to any physical device.  Nonetheless, since
  427. UNIMODEM (and other system modules) is such a handy beast, some people may
  428. wish to emulate a "virtual modem".  Thus, UNIMODEM will think that there is
  429. actually a modem attached to the port, when there is really only the port
  430. driver.
  431.  
  432. The easy way to approach this is to pick a modem and emulate it.  This
  433. requires some modes and states within the port driver, but it isn't too
  434. difficult (just time-consuming).  A good place to start is with the "Hayes AT
  435. Command Reference".  To be supported as the W95 "Standard Modem", there are
  436. very few AT commands that must be recognized.  See \WINDOWS\INF\MDMGEN.INF for
  437. what needs to be supported.
  438.  
  439. The "better" method is to write your own modem INF file.  There are examples
  440. in \WINDOWS\INF\MDM*.INF.  There is a lot of documentation for this in the
  441. MSDN DDK.  It is also possible for your virtual modem to be auto-detected by
  442. W95.
  443.  
  444. A similar approach can be taken for printers.
  445.  
  446.  
  447. 7.8:  Point-to-Point Protocol (PPP)
  448. ===================================
  449.  
  450. [Contributed by Taed Nelson (nelson@lan.nsc.com).]
  451.  
  452. Microsoft Dial-Up Networking uses asynchonous PPP.  Most, if not all, ISDN
  453. systems use synchronous PPP.  Therefore, to communicate over ISDN, your port
  454. driver or the hardware must convert between async and sync PPP.  This isn't
  455. actually too hard, and is described in RFC 1662.
  456.  
  457.  
  458. 7.9:  How to Monitor or Intercept COMM Data Traffic
  459. ===================================================
  460.  
  461. There is a Microsoft Knowledge Base article on this topic:
  462.  
  463.     How to Monitor or Intercept COMM Data Traffic in Windows 95   
  464.     ID: Q141230    CREATED: 13-DEC-1995   MODIFIED: 14-DEC-1995
  465.  
  466. [It is not on the January 1996 Library CD, so check the VCOMM archive
  467. "vcomm.9602".]
  468.  
  469.  
  470. 7.10:  HyperTerminal Function Trace
  471. ===================================
  472.  
  473. [Contributed by Taed Nelson (nelson@lan.nsc.com).]
  474.  
  475. This trace is from a port driver that uses Vireo's VtoolsD, but the
  476. translations to normal port driver functions should be obvious.  All numbers
  477. are in hexadecimal.
  478.  
  479. This was done by opening HyperTerminal with a script that uses COM5, hitting
  480. the Cancel button, typing a single return character, hitting the disconnect
  481. button, and then quitting HyperTerminal.  The Writes that are seen are thus
  482. the return character, and then the normal UniModem "ATZ<CR>".
  483.  
  484. Note that after the return character is written, there is no "Callback:
  485. CN_RECEIVE".  This is because the Read threshhold is 50, but only 1 character
  486. was received.  (A character was received since the virtual modem echos
  487. characters in command mode.)  But what is not seen in this trace is that,
  488. since dwLastReceivedTime was kept updated, VCOMM did a "Callback: CN_RECEIVE"
  489. when a certain timer expired.  HyperTerminal then does a Read a short time
  490. later.  See other sections in this FAQ for mor information.
  491.  
  492. Obviously, pointers and some other values should not match anyone else's
  493. traces, but the sequence of function calls should be nearly identical.
  494.  
  495. OnSysDynamicDeviceInit
  496. DriverControl (function=00000000)
  497. DC_Initialize (handle=c17cac74, iobase=00000000, irq=00000000, name=COM5)
  498. Initialize (m_name=C16B4A30, baseIO=00000000, irq=00000000)
  499. Open (hVM=C3D20154, pError=C15F5E20)
  500. EnableNotification (pCallback=C1737E2E, refData=C65A0018)
  501. EscapeFunction (lFunc=00000013, InData=C65A00A0, pOutData=00000000)
  502. SetModemStatusShadow (pMSRShadow=C65A0050)
  503. SetReadCallback (RxTrigger=FFFFFFFF, pCallback=00000000, refData=00000000)
  504. ClearError (pComstat=00000000, pError=C15F5DE8)
  505. Read (buf=C65A068C, cbRequest=00000001, pRxCount=C15F5E00, RxCount=00000000)
  506. Purge (qType=00000001)
  507. ClearError (pComstat=00000000, pError=C15F5E0C)
  508. SetReadCallback (RxTrigger=00000001, pCallback=C173804C, refData=C65A0658)
  509. GetCommState (pDCB=C15F5DF4)
  510. SetCommState (pDCB=C15F5DF4, ActionMask=FFFFFFFF)
  511. EscapeFunction (lFunc=00000005, InData=00000000, pOutData=00000000)
  512. EscapeFunction (lFunc=00000003, InData=00000000, pOutData=00000000)
  513. EscapeFunction (lFunc=00000010, InData=00000000, pOutData=00000000)
  514. EscapeFunction (lFunc=00000014, InData=00000000, pOutData=00000000)
  515. Setup (RxQueue=00000000, cbRxQueue=00001000, TxQueue=00000000, cbTxQueue=00000000)
  516. Setup (RxQueue=00000000, cbRxQueue=00001000, TxQueue=00000000, cbTxQueue=00001000)
  517. GetCommState (pDCB=C15F5E58)
  518. SetCommState (pDCB=C15F5E58, ActionMask=FFFFFFFF)
  519. EscapeFunction (lFunc=00000005, InData=00000000, pOutData=00000000)
  520. EscapeFunction (lFunc=00000003, InData=00000000, pOutData=00000000)
  521. SetReadCallback (RxTrigger=FFFFFFFF, pCallback=C1737E2E, refData=C65A0018)
  522. SetWriteCallback (TxTrigger=FFFFFFFF, pCallback=C1737E2E, refData=C65A0018)
  523. SetEventMask (mask=00000080, pEvents=00000000)
  524. Setup (RxQueue=00000000, cbRxQueue=00008000, TxQueue=00000000, cbTxQueue=00008000)
  525. GetCommState (pDCB=C15F5E58)
  526. GetCommState (pDCB=C15F5E58)
  527. GetCommState (pDCB=C15F5E58)
  528. SetCommState (pDCB=C15F5E58, ActionMask=FFFFFFFF)
  529. EscapeFunction (lFunc=00000005, InData=00000000, pOutData=00000000)
  530. EscapeFunction (lFunc=00000003, InData=00000000, pOutData=00000000)
  531. SetEventMask (mask=000000A0, pEvents=C65A0048)
  532. GetQueueStatus (pComstat=C15F9E20)
  533. SetReadCallback (RxTrigger=00000050, pCallback=C1737E2E, refData=C65A0018)
  534. GetQueueStatus (pComstat=C1618E20)
  535. SetWriteCallback (TxTrigger=00000001, pCallback=C1737E2E, refData=C65A0018)
  536. Write (buf=00668D94, cbRequest=00000001, pTxCount=C1684CB4)
  537. Callback: CN_TRANSMIT
  538. SetReadCallback (RxTrigger=FFFFFFFF, pCallback=C1737E2E, refData=C65A0018)
  539. Read (buf=C1603AD8, cbRequest=00000050, pRxCount=C1684CF0, RxCount=00000001)
  540. SetWriteCallback (TxTrigger=FFFFFFFF, pCallback=C1737E2E, refData=C65A0018)
  541. GetQueueStatus (pComstat=C1618E74)
  542. GetQueueStatus (pComstat=C15F9E20)
  543. SetReadCallback (RxTrigger=00000050, pCallback=C1737E2E, refData=C65A0018)
  544. SetEventMask (mask=000000A0, pEvents=C65A0048)
  545. GetEventMask (mask=000000A0, pEvents=00BBFF58)
  546. SetReadCallback (RxTrigger=FFFFFFFF, pCallback=00000000, refData=00000000)
  547. ClearError (pComstat=00000000, pError=C15F5E44)
  548. Read (buf=C65A068C, cbRequest=00000001, pRxCount=C15F5E5C, RxCount=00000000)
  549. Purge (qType=00000001)
  550. ClearError (pComstat=00000000, pError=C15F5E68)
  551. SetReadCallback (RxTrigger=00000001, pCallback=C173804C, refData=C65A0658)
  552. SetWriteCallback (TxTrigger=FFFFFFFF, pCallback=00000000, refData=00000000)
  553. SetEventMask (mask=00000000, pEvents=00000000)
  554. Purge (qType=00000000)
  555. ClearError (pComstat=00000000, pError=C15F5E84)
  556. EscapeFunction (lFunc=00000006, InData=00000000, pOutData=00000000)
  557. Purge (qType=00000000)
  558. Purge (qType=00000001)
  559. SetEventMask (mask=00000004, pEvents=00000000)
  560. Write (buf=C170829C, cbRequest=00000004, pTxCount=C65A0508)
  561. Callback: CN_TRANSMIT
  562. Callback: CN_EVENT=00000004
  563. Callback: CN_TRANSMIT
  564. Callback: CN_EVENT=00000004
  565. Callback: CN_TRANSMIT
  566. Callback: CN_EVENT=00000004
  567. Callback: CN_TRANSMIT
  568. Callback: CN_EVENT=00000004
  569. Callback: CN_TRANSMIT
  570. Callback: CN_EVENT=00000004
  571. Callback: CN_TRANSMIT
  572. Callback: CN_EVENT=00000004
  573. Callback: CN_TRANSMIT
  574. Callback: CN_EVENT=00000004
  575. Callback: CN_EVENT=00000004
  576. Close
  577.  
  578.  
  579. 7.11:  Blockable Functions
  580. ==========================
  581.  
  582. [Contributed by Joe Cossette (joec@infoark.com).]
  583.  
  584. Basically, due to the type of driver we needed (a virtual COMM port over a
  585. network), we needed to block at times when VCOMM called back on Port
  586. functions.  We eventually discovered (painfully...) that for many Port
  587. functions this just wasn't possible.  It would initially appear that some
  588. would function OK (you could block), but after a certain number of calls into
  589. it the system would typically hang (stop processing messages).
  590.  
  591. So we eventually separated the functions into 2 groups (based on looking over
  592. VCOMM docs).  The first group was composed of Port functions that could not be
  593. blocked and the second was composed of Port functions that might be a
  594. candidate for blocking.
  595.  
  596. What follows is the list of Port functions separated into the 2 categories we
  597. eventually came up with (that appeared to work for us).  We make no guarantees
  598. on these, not that we've actually blocked on each of the functions listed
  599. (we've blocked on some).  Simply, this is the information we've gleaned from
  600. reading the docs and some of our experiences.  Maybe others can concur/dispute
  601. these findings and hopefully our cumulative knowledge of VCOMM will increase
  602. by understanding this.
  603.  
  604. The blockable functions are roughtly the same thing as asynchronous functions,
  605. but I think the VCOMM docs didn't always indicate they were asynchronous.
  606. Sometimes they said they were "safe" (I think???).
  607.  
  608. Blocking means to block (i.e. put the thread to sleep, typically to be awoken
  609. at some later time).  During the blocked period the system runs other threads
  610. (if there're any to run).
  611.  
  612. The blocking mechanism can be whatever the system might have available to
  613. accomplish this sort of thing (i.e. semaphore, mutex, sleep functions,
  614. etc.,...).
  615.  
  616. 7.11.1:  Blockable Port functions
  617. ---------------------------------
  618.  
  619. PortOpen()
  620. PortClose()
  621. PortGetCommState()
  622. PortGetProperties()
  623. PortSetup()
  624. PortPurge()
  625. PortEnableNotification()
  626. PortSetEventMask()
  627. PortSetModemStatusShadow()
  628. PortSetReadCallBack()
  629. PortSetWriteCallBack()
  630.  
  631. 7.11.2:  Non-Blockable Port functions
  632. -------------------------------------
  633.  
  634. PortSetCommState()
  635. PortTransmitChar()
  636. PortGetQueueStatus()
  637. PortClearError()
  638. PortEscapeFunction()
  639. PortGetEventMask()
  640. PortWrite()
  641. PortRead()
  642. PortGetModemStatus()
  643. PortGetCommConfig()
  644. PortSetCommConfig()
  645. PortGetWin32Error()
  646. PortDeviceIOCtl()
  647.  
  648.  
  649. 7.12:  Support for DOS Applications
  650. ===================================
  651.  
  652. [Contributed by John Loram (johnl@turbocom.com).]
  653.  
  654. The Problem:
  655.  
  656. A DOS application running under Windows 95 or Windows for Workgroups 3.11
  657. cannot access VCOMM port driver supported devices such as a host-based modems.
  658. This is because the DOS app interacts with a serial communications channel by
  659. way of the Windows COMBUFF module. COMBUFF is UART-based virtual device driver
  660. (VxD) that engages in direct UART manipulation.
  661.  
  662. The Solution:
  663.  
  664. COMBUFF must be completely rewritten to serve as a translation layer between a
  665. DOS app's UART based I/O activity and the VCOMM's API. Doing so provides DOS
  666. apps access to the full range of VCOMM port drivers and the standard or
  667. non-standard devices these port drivers serve.
  668.  
  669. Specifically, COMBUFF must be expanded to include full, 8250, 16450, and 16550
  670. UART register-level emulation complete with appropriate interrupt-generation
  671. capability.
  672.  
  673. In addition, the initialization and contention-handling mechanisms of VCD must
  674. be revised significantly.  Separate versions of COMBUFF and VCD must be
  675. created for Windows 95 and WFW 3.11, since there are major differences in the
  676. code base for these environments.
  677.  
  678. TurboCom ViP (Pacific CommWare) is a finished product that accomplishes these
  679. objectives.  For further information, contact John Loram at
  680. johnl@turbocom.com, call him at 541-482-2744 (Ashland, Oregon), or check their
  681. web site at http://www.turbocom.com/.
  682.  
  683.  
  684.  
  685. ==============================
  686. 8:  Problems With Applications
  687. ==============================
  688.  
  689.  
  690. 8.1:  HyperTerminal Closes the Port Unexpectedly
  691. ================================================
  692.  
  693. [Contributed by Taed Nelson (nelson@lan.nsc.com).]
  694.  
  695. A few people have run into the problem where, under Windows 95, HyperTerminal
  696. will seem to load the port driver correctly, but then suddenly close it for no
  697. apparent reason.
  698.  
  699. The cause of this is that HyperTerminal or UNIMODEM (it is not clear which is
  700. the actual culprit) requires at least two of the four new W95 functions.  See
  701. below for more details.  The functions it needs to use are PortGetCommConfig
  702. and PortSetCommConfig.
  703.  
  704. [See also "HyperTerminal Function Trace".]
  705.  
  706.  
  707. 8.2:  HyperTerminal Zmodem Protocol Fails
  708. =========================================
  709.  
  710. A few people have seen the Zmodem protocol fail with errors such as "bad
  711. packet format" on the receiving side.  Other protocols seem to work just fine.
  712. While this has been seen mostly with our own VCOMM ports, one person said that
  713. they saw it on a high-speed modem with compression on.
  714.  
  715. The current theory is that this has something to do with high-speed data
  716. transmission, but Hilgraeve has not responded.
  717.  
  718. The 28800 Modem FAQ (http://web.aimnet.com/~jnavas/modem/faq.html) suggests
  719. that it may be caused by overrun errors.
  720.  
  721. There is also some data that implies that the problem is actually caused by
  722. running the DDK Windows 95 debug kernel.
  723.  
  724.  
  725. 8.3:  HyperTerminal Allocates No Buffers
  726. ========================================
  727.  
  728. [Contributed by Mike Melo and Michael Grabelkovsky (michael@slink.co.il).]
  729.  
  730. HyperTerm has problems when configured to use "Direct to COMx".  The port
  731. driver only receives a single PortSetup call, and TxQueue and cbTxQueue are
  732. both zero.
  733.  
  734. It's undocumented, but SERIAL.VXD includes special support for this case.  You
  735. can look at the SERFUNC.ASM module, function PortWrite.  The code is
  736. understandable.
  737.  
  738.  
  739. 8.4:  HyperTerminal can't work at high DTE speed
  740. ================================================
  741.  
  742. [Contributed by Michael Grabelkovsky (michael@slink.co.il).]
  743.  
  744. HyperTerminal loses some data when it receives a long text file from another
  745. HyperTerminal at a high speed.
  746.  
  747. My download driver sometime wrote up to 1024 bytes to receive queue in one
  748. time.  According the trace HyperTerminal successfully read the data. Each time
  749. it asks 80 bytes.  After about 800 bytes it starts to ask shorter and from
  750. this place data is lost.  Serial driver hasn't this problem because it writes
  751. not more 16 bytes at one time.
  752.  
  753. I fixed it by changed my driver writes to receive queue small portion of data
  754. every 20ms according defined DTE speed.
  755.  
  756.  
  757. 8.5:  Control Panel | Modems | More Info...
  758. ===========================================
  759.  
  760. [Contributed by Michael Grabelkovsky (michael@slink.co.il).]
  761.  
  762. Two things must be done properly before the "More Info..." option of Control
  763. Panal's Modems actually calls the ATIx commands to get "More Info":
  764.  
  765. 1. The port driver EscapeFunction() must support the GETCOMBASEIRQ option.
  766. "More Info" fell down when the driver answered with IE_EXITINVALID.  The
  767. function may return 0, though.
  768.  
  769. 2. The virtual modem (port driver) must support following AT commands and
  770. answer OK on the string: "ATE0Q0V1".  The last commands are not set up in the
  771. Modem's INF file, but it's used by "More Info".  After that Modem will be
  772. asked ATI1, ATI2 ... ATI7 and in the end the FAX capabilities with
  773. "at+fclass=?".
  774.  
  775.  
  776.  
  777. =======================
  778. 9:  Problems with VCOMM
  779. =======================
  780.  
  781.  
  782. 9.1:  PortOpen Causes VCOMM to Crash
  783. ====================================
  784.  
  785. [Contributed by Michael Grabelkovsky (michael@slink.co.il).]
  786.  
  787. If the PortOpen() function return FALSE (unsuccessful), but *pError remains
  788. unchanged, VCOMM crashes at VCOMM(04)+974.
  789.  
  790.  
  791. 9.2:  Illegal Baud Rate Indexes
  792. ===============================
  793.  
  794. [Contributed by Taed Nelson (nelson@lan.nsc.com).]
  795.  
  796. In a few different circumstances, SetCommState will be asked to use a CBR_
  797. baud rate index of 0xFF00.  According to all of the documentation I have seen,
  798. that is clearly an illegal baud rate.
  799.  
  800. The "proper" thing to do is to return an error of IE_BAUDRATE.
  801.  
  802. My theory is that this is old behavior that has a special meaning, such as
  803. "set to lowest supported baud rate" or something like that.
  804.  
  805. One easy way to duplicate this behavior under Windows 95 is to run Modems in
  806. the Control Panel.  Click on the Diagnostics tab.  Select your virtual COM
  807. port.  Click on More Info.  One of the calls to SetCommState will have this
  808. illegal case.
  809.  
  810.  
  811. 9.3:  RxCallback does not preserve EBX.
  812. =======================================
  813.  
  814. [Contributed by Walter Oney and Taed Nelson (nelson@lan.nsc.com).]
  815.  
  816. At a minimum, the default VCOMM RxCallback does not preserve the EBX register,
  817. so you must "push EBX" prior to calling the callback, and "pop EBX"
  818. afterwards.  (Turning of compiler optimization will also solve it.)
  819.  
  820. It is unknown if it affects other callbacks or other registers.
  821.  
  822. For more detail, see Walter Oney's _Systems Programming in Windows 95_.
  823.  
  824.  
  825.  
  826. =========================
  827. 10:  Documentation Issues
  828. =========================
  829.  
  830. [Unless otherwise noted, all text in this chapter was contributed by Taed
  831. Nelson (nelson@lan.nsc.com) and Michael Grabelkovsky (michael@slink.co.il).]
  832.  
  833. These comments refer to VCOMM.DOC on the January 1996 MSDN DDK.  Some of them
  834. have been fixed in COMM.DOC on the April 1996 MSDN DDK.  Those fixes are not
  835. yet referenced in this document.
  836.  
  837.  
  838. 10.1:  CommNotifyProc
  839. =====================
  840.  
  841. The event type CN_RECEIVED should be CN_RECEIVE.
  842.  
  843. The use of EV_CTSS, EV_DSRS, EV_RingTe, and EV_RLSDS needs to be made clearer.
  844. Is the use of "in Windows 3.1" to distinguish it from "in Windows 95", from
  845. "in the hardware", or from "in the modem status shadow register"?  Do
  846. applications request these events in PortSetEventMask, or are they always
  847. passed up when the change state event occurs?
  848.  
  849. It is not clear what the events EV_CTSS2, EV_DSRS2, and EV_RING2 are for.
  850. They are also not defined in the vcomm.h file, and are not used in Serial.vxd.
  851.  
  852.  
  853. 10.2:  CommTimeouts
  854. ===================
  855.  
  856. Communications timeouts make use of the COMMTIMEOUTS structure in _PortData.
  857. The timeouts and callbacks, when using COMMTIMEOUTS, are handled by VCOMM.
  858.  
  859. Unfortunately, this seems to only work for Win32 applications, such as
  860. HyperTerminal.  (Oddly enough, Dial-Up Networking does not make use of
  861. CommTimeouts, but I'm not sure if it is due to it not being Win32 or something
  862. else.)
  863.  
  864. Serial.vxd implements its own form of 100 ms timeouts for received characters.
  865. This is implemented via escape functions that enable and disable the "timer
  866. logic".  This seems necessary for port drivers to implement if they want to
  867. efficiently handle non-Win32 applications.
  868.  
  869. Apparently, when a Win32 application is running, VCOMM will disable the timer
  870. logic via the escape function.  I don't know if it automatically enables it
  871. for non-Win32, or if it is up to the application.
  872.  
  873. [See also "dwLastReceivedTime".]
  874.  
  875.  
  876. 10.3:  PortEscapeFunction
  877. =========================
  878.  
  879. VCOMM.H defines and Serial.vxd supports more extended functions than are
  880. described in the DDK.  But the list of function of EscapeCommFunction (see
  881. SDK) is shorter then corresponding DDK's list.
  882.  
  883. In the newer "Comm.doc" document, the escape functions are very well
  884. documented.  There is a minor error in that Serial.vxd does NOT implement
  885. GETPORTHANDLE.
  886.  
  887.  
  888. 10.4:  PortGetCommConfig and PortSetCommConfig
  889. ==============================================
  890.  
  891. There is no documentation on these functions.
  892.  
  893. Serial.vxd doesn't handle the error conditions in these functions correctly.
  894. For example, PortGetCommConfig returns TRUE in all cases, even if dwSize is
  895. less than the size of the Win32 DCB structure (see serfunc.asm module).
  896.  
  897.  
  898. 10.5:  PortGetEventMask
  899. =======================
  900.  
  901. The description for dwEvents is wrong (a cut-and-paste error).  It should be
  902. something like "The location where the previous port event flags should be
  903. returned."  It could be copied from _VCOMM_GetCommEventMask.
  904.  
  905. There is some question on whether the previous events should be returned in
  906. dwEvents as-is, or if they should be masked with dwMask.  Serial.vxd does not
  907. mask them, and the _VCOMM_GetCommEventMask description implies that they
  908. should not be masked.  On the other hand, that does not seem to match the
  909. spirit of this function.  This should be spelled out in the documentation.  It
  910. is mentioned in the Knowledge Base article Q81143, "DOCERR:
  911. Get/SetCommEventMask Functions Documented Incorrectly", but that covers the
  912. SDK.
  913.  
  914. The VtoolsD documentation specifically states that they should be masked.
  915. "The port object must set flags at the DWORD location pointed to by pEvents to
  916. indicate which of the events specified by the mask have occurred".
  917.  
  918.  
  919. 10.6:  PortGetWin32Error
  920. ========================
  921.  
  922. There is no documentation on this function.
  923.  
  924. Serial.vxd does nothing with this function; it is just a stub.
  925.  
  926.  
  927. 10.7:  PortSetModemStatusShadow
  928. ===============================
  929.  
  930. The Vcomm documentation and the comments in the Serial.vxd source code
  931. describe a parameter called dwEventMask.  This parameter does not exist.  The
  932. actual code in Serial.vxd does not declare this parameter.
  933.  
  934.  
  935. 10.8:  VCOMM_Map_Win32DCB_To_Ring0 and VCOMM_Map_Ring0DCB_To_Win32
  936. ==================================================================
  937.  
  938. There is no documentation on these VxD calls.
  939.  
  940.  
  941. 10.9:  _PortData Structure
  942. ==========================
  943.  
  944. There needs to be a better description (like that found in the TAPI
  945. documentation for its structures, which uses a chart format) of which fields
  946. are read and written by VCOMM, and which should be read and written by the
  947. port driver.  And also a complete description of what each field is used for
  948. by VCOMM and the port driver.
  949.  
  950. 10.9.1:  Notification fields
  951. ----------------------------
  952.  
  953. The fields for support notification such as lpClientEventNotify,
  954. lpClientReadNotify, lpClientWriteNotify etc. are defined in the _PortData
  955. structure. But serial driver doesn't use it and defines similar additional
  956. fields inside _PortInformation structure.  Why?
  957.  
  958. Is it possible to use the fields within the port driver?  Serial.vxd keeps its
  959. own copy of the data, but does not update _PortData.  Does VCOMM copy this
  960. information into _PortData when it passes the SetCallback functions down to
  961. the port driver?
  962.  
  963. In all cases, the rules of using those fields must be documented.
  964.  
  965. 10.9.2:  dwLastReceivedTime
  966. ---------------------------
  967.  
  968. This field is not described.
  969.  
  970. It seems that every time a character is received (including echo characters
  971. and response codes from "virtual modems"), this field should be updated with
  972. the result of Get_Last_Updated_System_Time.  (See also
  973. Get_System_Time_Address.)
  974.  
  975. This seems to allow VCOMM to perform timeouts using the entries in the
  976. COMMTIMEOUTS structure.  This is also undocumented.
  977.  
  978. [See also "CommTimeouts".]
  979.  
  980. 10.9.3:  dwLastError
  981. --------------------
  982.  
  983. There are many more fields in VCOMM.H than are described in COMM.DOC.
  984. Serial.vxd makes use of some of these "extra" error values, such as
  985. IE_HARDWARE.  Additionally, COMM.DOC defines two that are not in VCOMM.H:
  986. IE_CHARWAITING and IE_TIMEOUT.
  987.  
  988. The descriptions of IE_DEFAULT differ significantly between COMM.DOC and
  989. VCOMM.H.  The first states "some general error occurred", while the second
  990. defines an "error in default params".  It seems that SERIAL.VXD uses it more
  991. as a catch-all error condition, rather than referring specifically to the
  992. passed parameters of a function.
  993.  
  994. Should this field be updated with the value 0 when a function returns
  995. successfully?  The wording of the Vcomm documentation is unclear as to whether
  996. it should contain the last actual error, or just the last return value.
  997. Serial.vxd writes a 0 much of the time, but often does not.
  998.  
  999.  
  1000. 10.10:  Other Structures
  1001. ========================
  1002.  
  1003. 10.10.1:  General
  1004. -----------------
  1005.  
  1006. Some of the structures have "version" entries, but what version should be
  1007. filled in or checked for?  Some of this can be inferred from the Serial.vxd
  1008. source, but how will developers know if it is updated?  This information
  1009. should be in the Vcomm.h file.
  1010.  
  1011. 10.10.2:  _COMM_CONFIG
  1012. ----------------------
  1013.  
  1014. This structure is not documented.
  1015.  
  1016. Some its fields can't be understood from the Serial.vxd source. For example,
  1017. it seems that the field cc_wVersion is defined with an error in it.
  1018.  
  1019.  
  1020. 10.11:  Terminology
  1021. ===================
  1022.  
  1023. 10.11.1:  RLSD
  1024. --------------
  1025.  
  1026. RLSD is used, but not defined.  It stands for Receive Line Signal Detect, and
  1027. is usually referred to as Carrier Detect, or DCD (Delta Carrier Detect).
  1028.  
  1029.  
  1030.  
  1031. ========================
  1032. 11:  VtoolsD Vcomm Class
  1033. ========================
  1034.  
  1035. [Unless otherwise noted, all text in this chapter was contributed by Taed
  1036. Nelson (nelson@lan.nsc.com) and Michael Grabelkovsky (michael@slink.co.il).]
  1037.  
  1038.  
  1039. 11.1:  General
  1040. ==============
  1041.  
  1042. The Vcomm example is not very useful, except to give an idea of where to
  1043. start.  It would be very nice to have a functional example.
  1044.  
  1045.  
  1046. 11.2:  Documentation Errors
  1047. ===========================
  1048.  
  1049. The errors listed here refer to the online help files, but many (if not all)
  1050. also exist in the printed documentation.
  1051.  
  1052. Many of the documentation errors in the Microsoft documentation are shared by
  1053. VtoolsD, since much of it is copied verbatim or only slightly modified.
  1054.  
  1055. [Fixed in version 2.02.] The main Vcomm page is missing a short description for
  1056. EscapeFunction.
  1057.  
  1058. [Fixed in version 2.02.] Missing ClearError (although it can be searched for).
  1059.  
  1060. [Fixed in version 2.02.] SetModemStatus should be SetModemStatusShadow.
  1061.  
  1062. [Fixed in version 2.02.] Missing data members m_chain and m_PortFlags.
  1063.  
  1064. [Fixed in version 2.02.] The online help can be searched to find the entries
  1065. for _VCOMM_Map_Win32DCB_to_Ring0 and _VCOMM_Map_Ring0DCB_To_Win32, but they
  1066. are not in the alphabetical or functional sections.
  1067.  
  1068.  
  1069. 11.3:  PortOpen Errors
  1070. ======================
  1071.  
  1072. [Fixed in version 2.02.] When it first returns NULL if it cannot find the port
  1073. (the message "Failed to acquire port"), it must update the pError variable
  1074. with IE_DEFAULT or some other type of error.  pError should not be set in the
  1075. other error case since pPort->Open had been called, and that would have a
  1076. chance to set it to a better value.
  1077.  
  1078. [Fixed in version 2.02.] It does not check to see if the port is already open.
  1079. Look at the SERIAL.ASM example of how to do this.  It should return IE_OPEN in
  1080. pError if this is detected.
  1081.  
  1082. The documentation for Open says that the port driver "may" choose to save hVM
  1083. in m_ownerVM, but there is no reason for the Open to do this since the class's
  1084. PortOpen already does it. It should probably be removed from the
  1085. documentation, since the port driver doesn't need to use it for anything else,
  1086. so why should it be responsible for updating it.
  1087.  
  1088. [Fixed in version 2.03.] [Contributed by Xianbin Wang (xwang@wco.com).]  A
  1089. number of us saw problems with illegal port "stealing", such as Control Panel
  1090. | Modems | More Info...  would take an open port from HyperTerminal.  This is
  1091. probably due to PortOpen returning the port handle (instead of NULL) when a
  1092. port is actually open.  Although, it does return an error value.  Apparently,
  1093. More Info looks for a NULL handle instead of the error value.
  1094.  
  1095.  
  1096. 11.4:  Contention Management Errors
  1097. ===================================
  1098.  
  1099. [Contributed by Taed Nelson (nelson@lan.nsc.com).]
  1100.  
  1101. VtoolsD version 2.02 uses a different contention management method for Windows
  1102. 95.  This new method is only documented in the new version of the VCOMM
  1103. documentation, which is available from the VCOMM archives.
  1104.  
  1105. The first problem was due to not reading the documentation closely enough.  In
  1106. my INF file, I specified the contention handler as *VCD for my port driver,
  1107. which is on a non-standard port, COM5.  I don't think that documentation makes
  1108. it clear if it is OK to use *VCD for non-standard ports, but it did not seem
  1109. to break under VTD 2.01.
  1110.  
  1111. Anyway, it is bad when using the new 2.02 way -- it will always say that it
  1112. failed to open the port in PortOpen.  I just removed the Contention entry for
  1113. my port in the Registry, and that seemed to fix it.  Without this entry, VCOMM
  1114. itself will do simple contention management.
  1115.  
  1116. [The remainder is believed to be fixed in version 2.03.]
  1117.  
  1118. The second problem is a minor but significant problem with Vireo's
  1119. implementation.  VCOMM will not release a port unless the port driver provides
  1120. a notification function.  (This seems like a stupid VCOMM requirement, but
  1121. that's another issue.)
  1122.  
  1123. The easy way around this is to override the function CtnNotifyHandler (I think
  1124. that's the name).  For me, I just return TRUE in this function.  I'm not sure
  1125. why this helps, since the base VcommPort provides one, but I have verified
  1126. this by stepping through the VCOMM assembly source.  For some reason, if it is
  1127. not overridden, the creation of the thunk will return NULL, and VCOMM does not
  1128. like it.  (Personally, I think that is a VCOMM misfeature, but it is
  1129. documented that way...)
  1130.  
  1131. The symptom of this bug is that you can open your port, and attempt to close
  1132. it (which fails, and you will hit a DEBUGWARN if you have that turned on), but
  1133. you will not be able to open it a second time without rebooting the machine.
  1134.  
  1135.  
  1136. 11.5:  Other Errors
  1137. ===================
  1138.  
  1139. The GetError member function should be renamed to GetWin32Error.  Although
  1140. just what a "Win32 Error" is remains a mystery.
  1141.  
  1142. [Fixed in version 2.02.] The parameters of VCOMM_Map_Ring3DCB_To_Ring0 are
  1143. just wrong.  Right now, it has VCOMM_Map_Ring3DCB_To_Ring0 (unsigned long *,
  1144. _dcb **).  It really should be VCOMM_Map_Ring3DCB_To_Ring0 (win32_dcb *, _dcb
  1145. *).  Thus, you need a structure in your copy of vcomm.h for a win32_dcb.  This
  1146. can be copied from \DDK\Include\Vcommw32.inc.
  1147.  
  1148. [Fixed in version 2.02.] The type of the referenceData in the parameters for
  1149. EnableNotification, SetReadCallback, and SetWriteCallback should be all the
  1150. same.  Right now, it has the first as a PVOID, and the latter two as DWORD.
  1151. The PCOMMNOTIFYPROC callbacks in Vthunks.h use PVOID, but DWORD seems to make
  1152. more sense.  Regardless, it should be consistent.
  1153.  
  1154. [Fixed in version 2.02.] In \vtd95\include\vcomm.h, the structure _COMM_CONFIG
  1155. is incorrect.  It contains a _win32_dcb, NOT a _DCB (which is for ring 0) --
  1156. the two sub-structures are different!  The sizeof (_COMM_CONFIG) should be
  1157. 0x34, not 0x45 as it is now.
  1158.  
  1159. [Fixed in version 2.02.] The VcommPort class does not initialize the data
  1160. member m_dcb.  It should probably at least initialize the length, and maybe
  1161. zero out the rest.  Or document that it is not initialized.
  1162.  
  1163. The VcommPort class should have a data member called m_commProp (of type
  1164. _COMMPROP).  Every port driver must have this structure (due to the function
  1165. GetProperties).  It should also be initialized in the same way as m_dcb above.
  1166.  
  1167.  
  1168. 11.6:  Makefiles and #defines
  1169. =============================
  1170.  
  1171. This is somewhat out of the scope of VCOMM, but it is useful information
  1172. nonetheless.
  1173.  
  1174. 11.6.1:  Turning off optimization (Taed's way)
  1175. ----------------------------------------------
  1176.  
  1177. [Fixed in version 2.02 with the addition of the COPTFLAGS define.]
  1178.  
  1179. [Contributed by Taed Nelson (nelson@lan.nsc.com).]
  1180.  
  1181. To make debugging easier, I turn off all optimizations, and attempt (but fail)
  1182. to get more debugging information, by editing \VTD95\Include\MS9.MAK to the
  1183. following:
  1184.  
  1185.     CFLAGS          = -W2 -Zp -Gs -c -bzalign -Zl -D_X86_ -DIS_32 \
  1186.               -DWANTVXDWRAPS -DVTOOLSD
  1187.     ASMFLAGS        = -DMASM6 -c -W2 -Cx -DCOFF -coff
  1188.  
  1189.     ! if $(DEBUG) != 0
  1190.     CFLAGS          = $(CFLAGS) -Od -Oi -DDEBUG -Zi
  1191.     ASMFLAGS        = $(ASMFLAGS) -DDEBUG -Zi
  1192.     ! else
  1193.     CFLAGS          = $(CFLAGS) -Ogaisb1
  1194.     ASMFLAGS        = $(ASMFLAGS)
  1195.     ! endif
  1196.  
  1197. 11.6.2:  Turning off optimization (Michael's way)
  1198. -------------------------------------------------
  1199.  
  1200. [Fixed in version 2.02 with the addition of the COPTFLAGS define.]
  1201.  
  1202. [Contributed by Michael Grabelkovsky (michael@slink.co.il).]
  1203.  
  1204. All of us have had a problem when the debugger (ICE) shifts the lines of the
  1205. program.  This is a recommendation improve the situation:
  1206.  
  1207. The next fragment is added to the project MAK file after the "!include
  1208. $(VTOOLSD)\..." statement:
  1209.  
  1210.     ! if $(DEBUG) == 1
  1211.     CFLAGS = $(CFLAGS) -Od
  1212.     ! endif
  1213.  
  1214. If the macros such as VxDJmp and VxDCall are used, they will not work
  1215. correctly without optimization.  The next pragma corrects the situation:
  1216.  
  1217.     #pragma optimize( "gas", on )   // enable optimization
  1218.     #pragma optimize( "gas", off )   // disable optimization
  1219.  
  1220. The last statements may be correctly used together with #ifdef DEBUG...
  1221. statement for the same goals.
  1222.  
  1223. 11.6.3:  Version resource
  1224. -------------------------
  1225.  
  1226. [Fixed in version 2.02.]
  1227.  
  1228. If you have a version resource file, such as <project>.vrc, it will be
  1229. overwritten by VtoolsD every time you do a build-all.
  1230.  
  1231. This can be avoided by editing the VtoolsD makefile.  For example, in
  1232. \VTD95\Include\MS9VXD.MAK, you can comment out the following lines:
  1233.  
  1234.     #$(VRCNAME):     $(VTOOLSD)\include\default.vrc
  1235.     #        copy $(VTOOLSD)\include\default.vrc $(VRCNAME)
  1236.  
  1237. 11.6.4:  Dependencies
  1238. ---------------------
  1239.  
  1240. Remember that your project makefile does not have full dependencies, unless
  1241. you generate them by hand.  For example, if you change a .H file, the
  1242. appropriate .C or .CPP file will not recompile.
  1243.  
  1244. This can be avoided by always doing a build-all (takes longer to compile),
  1245. generating the full makefile dependencies by hand (annoying to keep
  1246. up-to-date), or finding a PC version of the funky Unix tool MAKEDEPEND.
  1247.  
  1248. If anyone finds a PC version of MAKEDEPEND, please let the list know.
  1249. Surprisingly enough, it is not in the ever-dependable MKS Toolkit.
  1250.  
  1251. 11.6.5:  Assert versus ASSERT
  1252. -----------------------------
  1253.  
  1254. [Fixed in version 2.03 with the addition of a global #define.]
  1255.  
  1256. If you have used the ASSERT macro in the past, then you are used to ASSERT.
  1257. The VtoolsD version is spelled as Assert.  To make matters worse, ASSERT is
  1258. defined in MINIPORT.H as nothing!
  1259.  
  1260. To get around this, I commented the line out of MINIPORT.H, and added the
  1261. following to my project makefile:
  1262.  
  1263.     XFLAGS = -DASSERT=Assert
  1264.  
  1265. 11.6.6:  DEBUG versus _DEBUG
  1266. ----------------------------
  1267.  
  1268. Microsoft VC++ users are used to seeing the #define for _DEBUG.  VtoolsD uses
  1269. DEBUG.  (It may actually be useful to have different #defines for some
  1270. people.)  This is a trivial change to \VTD95\Include\MS9.MAK:
  1271.  
  1272.     CFLAGS = ... -DDEBUG -D_DEBUG ...
  1273.     AFLAGS = ... -DDEBUG -D_DEBUG ...
  1274.  
  1275. 11.6.7:  Avoiding the dprintf() call
  1276. ------------------------------------
  1277.  
  1278. When not compiling with DEBUG, the dprintf() function is still called, but it
  1279. is just a stub which does nothing.  The reason for this is that the C
  1280. pre-processor cannot handle macros with variable number of arguments.
  1281.  
  1282. To avoid this minimal overhead, many solutions have been proposed, but the one
  1283. suggested by David McCullough (davidm@stallion.oz.au) seems to be the best:
  1284.  
  1285.     #ifdef DEBUG
  1286.     #define DPRINTF        dprintf
  1287.     #else
  1288.     #define DPRINTF        0 && (* (int (*)(...)) 0)
  1289.     #endif
  1290.  
  1291. For the non-DEBUG case, it will first test the "0", which will never be TRUE,
  1292. and therfore it will never continue with the function call.  A NULL function
  1293. pointer is used, instead of dprintf(), to avoid the function being linked in.
  1294. With optimizations on, the entire statement should not generate any code.
  1295. (Although the format strings may still exist after linking.)
  1296.  
  1297.