Hey WindowWare, HELP
 

ISSUE 1 of 2:  (WIL-SDK) FLOPPY FLOPS 

WIL-SDK Execution

WILX32I.DLL with WILXTEST.WBT

MY Execution

MYWILX.DLL with WILXTEST.WBT

 

Everything works great until
the floppy functions.

  

What function am I missing?
See "What I Did" below.

 

   

  

I get the following fault with no
 diskette in A: after I click OK.

Your dll returns the correct,
"Is Not ready" message if I don't put diskette in A:


See DUMP/DEBUG info below.

 

WINBATCH caused an invalid page fault in
module MYWILX.DLL at 0167:1000190f.

Registers:
EAX=00000041 CS=0167 EIP=1000190f EFLGS=00010297
EBX=0064ed24 SS=016f ESP=0064eb34 EBP=0064ecdc
ECX=1002b09c DS=016f ESI=0064eb34 FS=12af
EDX=00000041 ES=016f EDI=0064ecdc GS=0000
Bytes at CS:EIP:
88 11 8b f4 6a 01 ff 15 6c 32 03 10 3b f4 e8 de 

Stack dump:
0000000e 0042007c 0064ed24 cccccccc cccccccc cccccccc cccccccc cccccccc
cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc 

 


AFTER HITTING THE DEBUG BUTTON THIS IS WHERE I AM ..

.

I did NOT change anything in the WILX project files...


 
 


What I Did - What Did I Do? 
 



This is my story and I'm stickin to it :)

     1.  Created a new "Win32 DLL Project (empty)"
     2.  Added the files on the right to the project
     3.  Compliled to MYWILX.DLL with no errors
     4   Modified the WILXTEST.WBT to 'point' to my DLL 

case 1                    ; Switch wiltype
;extdll = "wilx32i.dll"   ; Original Ext DLL 
extdll = "mywilx.dll"     ; My Ext DLL
Break

     4.  Ran the WILXTEST.WBT from WB Studio.

 


I found this note in the revision remarks in the WILX.C file.  But revisions only go through 11104 (hmm, my version?)  No revision comments for 11105 - 11108.  (11108 is the current wilx32i.dll version as shipped with the SDK and compiler I received)  I highlighted the comment below that caught my eye, making me think that I must be missing something somewhere, like the missing function as indicated at the top, and anything else that changed between the WILX.C-11104 I received with the SDK and the WILX.C-11108 that the current WILX32I.DLL is based on.


#define EXTENDERVERSION 11104 // DLL version number

Rev 11102 Apr 10, 1995 REM

Changed xDriveReady to support all drive types, not just floppies.
Fixed a problem with xDriveReady sometimes causing GP faults.
xDriveReady no longer uses assembly code.


FROM SUPPLIED WILX.C  COMMEXTSTRUCT:     

         {14, FUNCTION, 0x001F0001L, 0, "xdriveready" }, // xDriveReady(s)

FROM THE SWITCH:

case 14:
{
HFILE hFile;
OFSTRUCT ofsFile;
LPSTR lpTestFile = "?:\\NUL"; // NUL dev usually "exists" in each dir
char cDrive;
LONG nLen;
UINT uPrevErrorMode;

nLen = lstrlen(lp1);

if ((nLen < 1) || (nLen > 2))
RETERROR(-1, 141); // invalid drive letter (string)

if ((nLen == 2) && (lp1[1] != ':'))
RETERROR(-1, 141); // invalid drive letter (string)

cDrive = lp1[0];

if ((cDrive >= 'a') && (cDrive <= 'z'))
cDrive += ('A' - 'a'); // convert [a-z] to [A-Z]

if ((cDrive < 'A') || (cDrive > 'Z'))
RETERROR(-1, 141); // invalid drive letter <- I think the error occurs here 

// Obviously I dont have the WinBatch.bsc
// so the debugger could only drop me at the line following the error

lpTestFile[0] = cDrive; // fill in the drive letter 
<- Debug drops me off here

uPrevErrorMode = SetErrorMode(SEM_FAILCRITICALERRORS); // suppress dlg
hFile = OpenFile(lpTestFile, &ofsFile, OF_EXIST);
SetErrorMode(uPrevErrorMode); // restore previous error mode

if (hFile != HFILE_ERROR) // the file exists
RETLONG(1); // so, the drive is ready

if (ofsFile.nErrCode == 2) // file not found (it happens)
RETLONG(1); // still, this means the drive is ready

RETLONG(0); // drv not ready, or some other problem
}


WRAPPING UP THE WILX ISSUE:

OK, so, is there something my version (11104 WILX.c) file is missing that exists in your (11108 WILX.c) file?  Maybe the function #13 I'm missing noted at the top?  I'm unsure, but the outdated version of WILX.c that came with the compiler and the SDK appears to be the culprit.  Will the SDK diskette that shipped yesterday have the updated 11108 version of WILX.c or does it also contain the 11104 version?

 

ISSUE 2 of 2:  WEBBATCH AND SAMBAR SERVER

FINAL QUESTION REGARDING THE WEBBATCH / SAMBAR SERVER ISSUE:

You know, I actually had several paragraphs here, but I have summarized it this way.  I can find no reason why WebBatch isn't working with Sambar.   Admittedly, I am not a Web Configuration expert.  The problem may well reside therein.  I do not have intimate knowledge of what either WebBatch or Sambar is doing.  The features of this server, coupled with its price - FREE, and its ability to run on Windows95/98 make it an irresistable package.  I know you guys are into NT/IIS or Unix/Apache, but there is a niche that this product will own if the progress continues.  The server supports CGI, WinCGI, ISAPI Extensions, HTML Server Management, Proxy Services, etc... And does them all well, very well.

I don't expect Wilson to do this out of the goodness of their hearts.  Given that I am a consultant that bills for his time, what amount is going to solve this problem for me?  What would it cost me to have someone download the server (3 MB), install it (30 s),  drop WebBatch and supporting files into the Win-CGI directory (10 s), and determine what it is exactly that isn't working.  Marty thought it might be that the server isn't returning standard responses (See the WebBoard - WebBatch Licensing), I thought I might not have configured something I should have, Deana was unsure if WebBatch is compatible with Windows versions other than NT.  Each being a perfectly valid possibility, but neither putting us any closer to the solution.  I really need a solution.

I have written several WinBatch utilities to automate networking tasks, remote data collection and transmission tasks, quick database lookups & updates, etc...  WinBatch is what should have happened to DOS when it migrated into or was assimilated by Windows.  Shhh, don't tell Microsoft, you will be assimilated.  I would like to experience what WebBatch brings to the table, but if the client says Sambar, then Sambar it is.  WebBatch was purchased based on WinBatch's usefulness, and presently I can realize or demonstrate neither.

If the cost of determining what the exact problem and solution is exceeds the cost of WebBatch, then I guess I need an RMA#.  If not, then I eagerly await your findings and your invoice.  I see now that my several paragraphs have become so again, so thanks for your collective attention to this issue and I await either your quote or the RMA# for WebBatch.


 

Thanks for the help !!!

 



Scott Waters
Office Automation Technologies

Email:
  oatscc@aol.com