SLMYQ@USU.BITNET (05/23/88)
How do DOS allocated BSTRs work? I'm upgrading my CD program to change the cli_SetName variable so it works with BCPL commands like Copy and Delete. I need to be able to deallocate the old BSTR and allocate a new one. Also, for all those who wish they could use CD with ConMan: now you can. Both the old and the new one work with ConMan 1.1 (I tested it). If you threw it away before, I'll be posting the new CD pretty soon (as soon as I fix the BSTR problem). Bryan
hawes@dino.ulowell.edu (Bill Hawes) (05/25/88)
Bryan, The BSTR for cli_SetName is statically allocated -- as part of the CLI's (inverted) stack. Don't even think about releasing it, but simply blast in your new string. The buffer is 64 characters long (including the leading length byte). BTW, was there a problem with prior versions of ConMan with your CD program? Since ConMan is just an I/O handler, it should be independent of anything related to CLI structures. -- Bill (ConMan, WShell author)
SLMYQ@USU.BITNET (05/26/88)
>The BSTR for cli_SetName is statically allocated -- as part of the CLI's >(inverted) stack. Don't even think about releasing it, but simply blast >in your new string. The buffer is 64 characters long (including the >leading length byte). Ah, no wonder everything crashed when I EndCLI'ed! :) Will the buffer always be 64 characters long? Is there any way to find out how long the buffer is so that programs will be compatible with other OS versions? >BTW, was there a problem with prior versions of ConMan with your CD program? >Since ConMan is just an I/O handler, it should be independent of anything >related to CLI structures. My first version of the CD program didn't do this SetName things - that's not the problem. You'll have to tell me if I'm right or not, but it seems ConMan 1.0 didn't support the DiskInfo packet or maybe it just didn't put the correct window pointer into the InfoData structure. Both versions of my CD program work with ConMan 1.1 - I've tried it. > -- Bill (ConMan, WShell author) Bryan Ford (SLMYQ@USU.BITNET)