#: 15317 S1/NonTech Cust. Serv. 17-Oct-92 10:53:21 Sb: Device Driver Fm: Leon G Rollison 70421,1702 To: David Taniguchi 72350,2054 (X) Will a Device Driver for Always Technology's IN-2000 16 Bit SCSI Controller be available in the next preliminary release of the Windows NT SDK? #: 15320 S1/NonTech Cust. Serv. 17-Oct-92 15:48:21 Sb: SB,SCSI, and NT Fm: Chris Conlon 72401,1553 To: 70744,20 (X) Thanks Nancy. I'll try the NT setup/Install area #: 15358 S1/NonTech Cust. Serv. 19-Oct-92 09:43:53 Sb: Beta site for NT Fm: Swamy 74230,2520 To: sysop (X) Hi there - I would like to get on the Beta program for WINDOWS NT. We are developers of fax and modem software and were involved in the C++ 7.0 beta program. The Company ID assigned to us is 06032. We would to make our software compatible with the operating systems of the future and we strongly feel that WINDOWS NT will be the one for the fu So please do enroll us in the beta program. If you have any questions please do let me know and I will be happy to provide the answers. Looking forward to an early response. - Swamy Prabhakar #: 15355 S1/NonTech Cust. Serv. 19-Oct-92 08:33:57 Sb: NT DDK in Canada???? Fm: David Johnson 73557,1223 To: SYSOP (X) Will somebody at MS USA please inform MS Canada what the part number is for the NT DDK. MS Canada won't take orders unless they have a part number and, if history is any guide, this might take quite along time ie: it only took them 3 months to realize that there was such a thing as a Windows MDK. sigh. dwj There is 1 Reply. #: 15359 S1/NonTech Cust. Serv. 19-Oct-92 09:48:45 Sb: #15355-NT DDK in Canada???? Fm: Dwight Matheny/Microsoft 70750,2340 To: David Johnson 73557,1223 (X) I've passed this on to MS Canada. -Dwight (MS) #: 15338 S1/NonTech Cust. Serv. 19-Oct-92 03:50:33 Sb: #15218-Sections? Fm: Lee Hart [Microsoft] 76150,2536 To: Andrew Bradnan 70402,63 (X) It sounds like you don't have your forum options set properly. From the Forum ! prompt, type OPT, and at the Options menu, type SECT. Select all sections, and you should be able to see all sections from that point on. If you have further questions about forum access, please ask. Lee Microsoft Developer Support There is 1 Reply. #: 15386 S1/NonTech Cust. Serv. 19-Oct-92 14:59:05 Sb: #15338-Sections? Fm: Andrew Bradnan [Erudite 70402,63 To: Lee Hart [Microsoft] 76150,2536 (X) Lee Cool! Must have been set that way from before the PDC when there was only one section. Thanks much, Andy #: 15417 S1/NonTech Cust. Serv. 19-Oct-92 21:41:00 Sb: #15260-WIN32 Fm: Al Longyear 70165,725 To: Dan Sodhi 71212,2333 You might also check out the MS Developer Relations CDROM. There is a tool there to aid in the porting from 16 to 32 bit windows code should you decide to port to Windows NT or Win32s. #: 15330 S1/NonTech Cust. Serv. 18-Oct-92 08:20:59 Sb: #15274-compuserve support Fm: Scott Wheeler 100022,2005 To: John Oellrich 72611,1452 (X) Thanks for the advice - I hadn't expected that you would watch the forums. I'll try what you advise but I have tried several similar things in the past. Basically the modem responds as expected if I talk to it manually (eg Terminal, or CIM with direct connect) but ignores automatic controls (eg. CIM or Terminal doing the dialling). I've pretty well given up on it now, since I've found that I can do downloads from Kermit, but I'll have another rummage in the CMOS and see what I can find. Thanks again, Scott There is 1 Reply. #: 15348 S1/NonTech Cust. Serv. 19-Oct-92 06:09:01 Sb: #15330-compuserve support Fm: John Oellrich 72611,1452 To: Scott Wheeler 100022,2005 Scott, AT&V (dump parameters) can be a life saver. One other thing I forgot. With OzCIS I found that the COM port settings in Control Panel had to exactly match OzCIS's settings, otherwise it just kinda sat there and stared at me. John #: 15447 S1/NonTech Cust. Serv. 20-Oct-92 09:29:26 Sb: #15263-compuserve support Fm: John Mueller [DBA] 75300,576 To: Scott Wheeler 100022,2005 That's really strange. Are MODEMs designed for a Sun machine physically different than those designed for DOS machines? Just wondering in case I run across one someday. John Mueller #: 15395 S1/NonTech Cust. Serv. 19-Oct-92 16:22:38 Sb: WinNT SDK in S'pore Fm: Ricardo Nuqui 71203,1103 To: all I'd like to know if the Windows SNT SDK is available in Singapore, and how I could get one. I haven't tried contacting the local Microsoft office so I don't know if they can help. There is 1 Reply. #: 15481 S1/NonTech Cust. Serv. 20-Oct-92 14:22:20 Sb: #15395-WinNT SDK in S'pore Fm: Dwight Matheny/Microsoft 70750,2340 To: Ricardo Nuqui 71203,1103 I sent SDK product info to our subsidiary in Singapore last week, so they might be set up to place orders. You can reach them at 65-227-6833. Let me know if you have problems ordering. -Dwight (MS) #: 15506 S1/NonTech Cust. Serv. 21-Oct-92 07:03:57 Sb: Hi Jerry! Fm: Arthur Knowles 71041,2613 To: Jerry Drain [Microsoft] 72350,2056 (X) Jerry, Good to see you back here. i hope your vacation was a relaxing one. My last vacation was the PDK conference. TTYL... Art #: 15514 S1/NonTech Cust. Serv. 21-Oct-92 09:16:48 Sb: WINNT DDK Fm: Walter R Hoesch 70402,2145 To: SYSOP (X) I have received the DDK and would appreciate access to the section for support. Thanks, Walt #: 15508 S1/NonTech Cust. Serv. 21-Oct-92 08:33:46 Sb: 2nd SDK Ship Date Fm: prieur 3 71127,2447 To: Sysop (X) Do y'all still plan to ship the 2nd SDK before the end of October or has it changed yet again. How 'bout an exact date y'all will start shipping it ?? Thanks, Prieur Leary There is 1 Reply. #: 15528 S1/NonTech Cust. Serv. 21-Oct-92 12:52:20 Sb: #15508-2nd SDK Ship Date Fm: Dwight Matheny/Microsoft 70750,2340 To: prieur 3 71127,2447 (X) We still plan on shipping the October release of the Win32 SDK to all US customers before the end of the month. -Dwight (MS) There is 1 Reply. #: 15535 S1/NonTech Cust. Serv. 21-Oct-92 13:16:20 Sb: #15528-2nd SDK Ship Date Fm: prieur 3 71127,2447 To: Dwight Matheny/Microsoft 70750,2340 (X) Anytime soon ?? There is 1 Reply. #: 15560 S1/NonTech Cust. Serv. 21-Oct-92 15:52:56 Sb: #15535-2nd SDK Ship Date Fm: Dwight Matheny/Microsoft 70750,2340 To: prieur 3 71127,2447 (X) >>>> Anytime soon ?? Yes, before the end of the month which is ten days away. -Dwight #: 15356 S1/NonTech Cust. Serv. 19-Oct-92 08:39:33 Sb: #15291-Printer Spoolers Fm: Centre File 100015,3565 To: Stu Wiley 70473,1351 (X) Thanks for the information. I shall be going to the DDK conference in London on the 5th and 6th of November. There is 1 Reply. #: 15426 S1/NonTech Cust. Serv. 20-Oct-92 00:22:07 Sb: #15356-Printer Spoolers Fm: Peter A Winskill 70323,2547 To: Centre File 100015,3565 (X) Bonfire night at the DDK! Hope Guy isn't going too . #: 15570 S1/NonTech Cust. Serv. 21-Oct-92 18:42:07 Sb: #15356-Printer Spoolers Fm: Stu Wiley 70473,1351 To: Centre File 100015,3565 (X) Excellent. You will receive a boatload of pertinent info there. Enjoy. Stu Wiley #: 15561 S1/NonTech Cust. Serv. 21-Oct-92 15:53:05 Sb: MS: Oct SDK ships!! Fm: Dwight Matheny/Microsoft 70750,2340 To: ALL Attention all US SDK customers: Since there's been lots of discussion about this, I'll make it official. The October release of the Win32 Preliminary SDK for Windows NT started shipping to US customers today, 10/21. (Int'l customers: there is usually about a two week delay due to the fact that we ship first to the subsidiaries and that they in turn ship to you: contact your local MS office if you need more specific information.) There are two important things you need to know: 1. This release will be sent to you automatically. 2. We have more than 25,000 updates to ship, and we will be shipping several thousand each day. We hope to have all the updates shipped by the end of next week. If you do not receive your update by then I will post a phone # you can call to check status. Please do not call until then. This release of the Win32 SDK represents a significant improvement over the July release. Here is a brief list of the new features for this release. If you have specific questions, please ask them in the appropriate section on this forum or on WINNT. - Improved C++ compiler - Improved debugging with C++ support - A preliminary version of Win32s - Improved online Help - Tools for source code (call) and API profiling - Improved porting tool - Better sample applications - Documentation is now provided in both PostScript and Write formats - New file comparison program-WINDIFF.EXE - POSIX development support - New UNICODE development support - Setup toolkit This version of Windows NT also has significant enhancements relative to the July release. - Improved MS-DOS and 16-bit Windows application support - Performance improvements such as console output and scrolling - Fully functional Windows NT File System (NTFS) - Feature complete except for Network DDE, Schedule+, and Mail - Greater hardware compatibility - New video support such as high-resolution S3 VGA video support Good luck on developing great 32-bit Windows applications! I'm off to the DDK conference, be back on Thurs 10/29. -Dwight Matheny SDK Product Manager There are 4 Replies. #: 15568 S1/NonTech Cust. Serv. 21-Oct-92 18:04:47 Sb: #15561-MS: Oct SDK ships!! Fm: Graham Welland 70023,1267 To: Dwight Matheny/Microsoft 70750,2340 (X) Excellent...... oh well, 14 days to go.......... (in UK) #: 15580 S1/NonTech Cust. Serv. 21-Oct-92 23:47:35 Sb: #15561-MS: Oct SDK ships!! Fm: Mike Walsh (Helsinki) 72557,3170 To: Dwight Matheny/Microsoft 70750,2340 (X) I'm not happy about the upgrade coming "via your local MS office". Based on past experience your 14 days is likely to be way off mark, and I will probably have at least of month of reading messages here from US developers about it before it arrives on my desk. (I'll post to you when it does arrive - don't hold your breath) Mike #: 15589 S1/NonTech Cust. Serv. 22-Oct-92 03:00:04 Sb: #15561-MS: Oct SDK ships!! Fm: Peter A Winskill 70323,2547 To: Dwight Matheny/Microsoft 70750,2340 (X) Please personally mail the october release to helsinki_mike...I'm tired of his whining! #: 15602 S1/NonTech Cust. Serv. 22-Oct-92 10:24:38 Sb: #15561-MS: Oct SDK ships!! Fm: John Mueller [DBA] 75300,576 To: Dwight Matheny/Microsoft 70750,2340 (X) That's fantastic news! I'm looking forward to receiving the new update. BTW, is that going to be Friday of this week (the 23rd) or Friday of next week? What should we expect in regards to DOS and Windows support? TIA. John Mueller There is 1 Reply. #: 15617 S1/NonTech Cust. Serv. 22-Oct-92 12:58:08 Sb: #15602-MS: Oct SDK ships!! Fm: Dwight Matheny/Microsoft 70750,2340 To: John Mueller [DBA] 75300,576 >>is that going to be Friday of this week (the 23rd) or Friday of next week? We hope to have all the updates shipped by the end of next week, Fri 10/30. We're shipping 10,000 today. >>What should we expect in regards to DOS and Windows support? This is not something I'm really involved with, except from a user standpoint. My perception is that the Windows apps that I use run quite a bitfaster. I don't really use DOS apps, so I haven't tried any. I especially like the faster scrolling in the command-line box. -Dwight #: 15593 S1/NonTech Cust. Serv. 22-Oct-92 07:24:29 Sb: Win32 release Fm: David Botton 71043,2465 To: ALL I currently have the July 1992 Preliminary release of Win32 when is the next release due and will it have the DLLs for Windows 3.1 to suport the Win32 SDK? David Botton There is 1 Reply. #: 15656 S1/NonTech Cust. Serv. 22-Oct-92 17:31:19 Sb: #15593-Win32 release Fm: Jerry Drain [Microsoft] 72350,2056 To: David Botton 71043,2465 Hi David, << I currently have the July 1992 Preliminary release of Win32 when is the next release due>> They're being shipped now. We're reproducing them and shipping them just as fast as the machines can dupplicate them, but with about 25,000 copies to make, and the time to mail them, it will probably take a couple of weeks to get to you. If you don't have your copies within a couple of weeks, let us know. << and will it have the DLLs for Windows 3.1 to suport the Win32 SDK?>> If you are asking about Win32S: yes, it is supported with this release. Thanks, -- Jerry [@Microsoft] #: 15659 S1/NonTech Cust. Serv. 22-Oct-92 17:31:38 Sb: #15309-Windows NT Fm: Jerry Drain [Microsoft] 72350,2056 To: Egbert 100113,1011 Hi Egbert, <> Let me please direct you to the WINNT forum, Section 3. They handle the OS setup issues, and will be most familiar with your problem. Thanks, -- Jerry [@Microsoft] #: 15488 S1/NonTech Cust. Serv. 20-Oct-92 15:41:22 Sb: Where to post? Fm: Otto Fung 76260,631 To: Sysop (X) Hello Sysop, I now have my system ready to produce MSWIN32 archived messages. I need some information. 1) Which section should I post it? 2) Any suggestion for naming the file? My plan is to use WIN32_##.ZIP while ## is the number of weeks. And therefore, I also need the number of week this forum has been operated. I will post starting this week and will do so weekly. Otto Fung There is 1 Reply. #: 15664 S1/NonTech Cust. Serv. 22-Oct-92 17:38:23 Sb: #15488-Where to post? Fm: Stu Wiley 70473,1351 To: Otto Fung 76260,631 Great! I'm sure your peers are very pleased, and we all thank you. Your efforts are appreciated. I would suggest a library, but let me check with all parties and see what the concensus is. Stu Wiley Developer Service Team #: 15498 S1/NonTech Cust. Serv. 20-Oct-92 21:11:56 Sb: For Jerry Drain Fm: Jerry Drain [Microsoft] 72350,2056 To: Mike Walsh (Helsinki) 72557,3170 (X) Hi Mike, Sorry for not getting back to you quickly, I've been away from my office for about the last week. You may note for the future, that when you address something specifically to an individual (as you addressed this to me), other Microsoft folks may not jump in to answer your question. They may figure that this is an on going dialog between the two of us, where I'm researching your questions or something. I might just actually be away for a few days (as I was). So you might not get your questions answered. In the future, you might address any questions you want any Microsoft people to jump in on, to sysop or to Microsoft. Regarding your question: << Last week I asked here (WINNT) about the UK price for the Dev. CDROM saying that I wanted to answer an Internet meesage. >> I'm confused when you say the "Dev. CDROM". This might be part of the problem with your other contacts too. Are you talking about the MSDN CD (Microsoft Developer's Network CD.)? I'm not sure what the confusion between the two different people came from. You will find me starting to visit the other sections handling more technical issues, and that will cause me to lose touch with the details of some of these issues. If this is important to you, I can try and contact people regarding this. More than likely I think there is some sort of a communication problem of some kind. You haven't given me enough details to work with. If you want me to pursue this, you can send me a private post with the names of the folks you talked to and how you were in touch with them etc. << To date (Thursday) I have had no reply to any of my points. To me this shows a willingness to react quickly if money is likely to come in, but no willingness to improve what I think you could agree is pretty terrible service. (i.e. Sales - great !; Support - what ?) >> I think you've drawn some wrong conclusions here, and I can't agree with you about the service being terrible. Again, let me say, these guys have a tough job, and they don't have some of the luxuries that I can rely on. I [More] There is 1 Reply. #: 15499 S1/NonTech Cust. Serv. 20-Oct-92 21:12:02 Sb: #15498-For Jerry Drain Fm: Jerry Drain [Microsoft] 72350,2056 To: Jerry Drain [Microsoft] 72350,2056 (X) [Continued] can't answer the "why" part of this question without talking to some people and finding out the details. Like as not though, again there are some communication problems. << P.S. My questions were fairly simple like - whether the "local" newsletter would be in English; why they did not simply send us the US newsletter; why the price still hadn't been set; nothing aggressive !>> You?! Not being aggresive ?! Just kidding. Let me check into these questions for you. I'll try and get back to you tomorrow or the next day. Thanks, -- Jerry [@Microsoft] #: 15542 S1/NonTech Cust. Serv. 21-Oct-92 13:58:41 Sb: For Jerry Drain Fm: Jerry Drain [Microsoft] 72350,2056 To: Mike Walsh (Helsinki) 72557,3170 (X) Hi Mike, Found some more information for you. I'm not sure who it was you talked to in Sweden, but I understand the person heading up MSDN CD distribution responsibilities there is Magnus Anderson (MS-SCANDANAVIA). I haven't found out yet what the prices of the CD there has been set to yet, or even if it has been set. I believe MS-UK is set by different people (probably Brian Iddon, but I'm not sure). If this is the case, they may be two different prices, set at two different times. If you find otherwise, please let me know, but this sounds like the source of some of your confusion. Regarding the language the newspaper will be printed in, I understand that it will depend on the local offices. We will not be sending the paper directly to international developers, so it will be up to the local offices if they will distribute a translated copy or the US copy. They may not have decided on this at MS SCANDANAVIA yet. Again, Magnus should be able to help you. I hope this helps you to understand things better. If you have more MSDN questions, there is an MSDN forum called MSDNLIB. Perhaps you can find more information there. Thanks, -- Jerry [@Microsoft] There is 1 Reply. #: 15584 S1/NonTech Cust. Serv. 21-Oct-92 23:51:18 Sb: #15542-For Jerry Drain Fm: Mike Walsh (Helsinki) 72557,3170 To: Jerry Drain [Microsoft] 72350,2056 (X) No confusion, Jerry. Magnus Andersson *is* the guy who has ignored my questions since the 4th and Brian Iddon hasn't posted the UK price officially here either (as far as I have read all messages). As for local language, many many more EDP Finns speak English than Swedish, even though Swedish is an official language here. Anything other than an English-language newsletter would be an unfortunate sign of Swedish arrogance - Sweden being the largest Nordic country tends to throw its weight around; Canadians might see some similarities). Mike There is 1 Reply. #: 15667 S1/NonTech Cust. Serv. 22-Oct-92 17:56:16 Sb: #15584-For Jerry Drain Fm: Jerry Drain [Microsoft] 72350,2056 To: Mike Walsh (Helsinki) 72557,3170 (X) Hi Mike, I'm not sure if you are somehow singularly experiencing these difficulties, or if you are looking at them with a negative light, or what? I've sent mail to Magnus, and he has not yet responded to me. This suggests to me that he may be away from his office or tied up in some other respect. I'm fairly sure he's not ignoring me, and I doubt that he means to be ignoring you. Please try and contact him again. If he is not available, ask for someone else that can help you. Regarding the MS-UK, again, give them a call and ask them your questions directly. I wouldn't have expected them to make a global announcement about local prices on this forum, but they should be able to answer your questions if you ask them. If they haven't set a price yet, ask them when it will be set. Regarding the issue of local language, again, make your needs known to MS SCANDANAVIA. I'm sure that they are interested in your input, but please don't word it in such a way as to accuse them of throwing their weight around or suggest they are about to commit an act of "Swedish arrogance". I'm sure this will only tend to alienate the person you talk to. Thanks, -- Jerry [@Microsoft] #: 15701 S1/NonTech Cust. Serv. 23-Oct-92 11:35:11 Sb: Oracle and NT Fm: Paul Sutter 70451,1500 To: Jerry Drain [Microsoft] 72350,2056 (X) Jerry, Thanks for checking into Oracle ODBC support for NT. I will see what I can find out from Oracle. I would like to point out that having ODBC drivers that support *local* (that is *efficient*) access to the major databases servers running under NT would be a very powerful argument for us to completely ditch our Unix server development plans and concentrate on NT as a server platform for our products. Paul Sutter Voila! Software #: 15558 S1/NonTech Cust. Serv. 21-Oct-92 15:21:55 Sb: Lan Manager licensing Fm: William Lees 75300,250 To: All This is a fragment of a message from another section: mswin32/S12_API-RPC_WinNet #15392, from Bruce_Ramsey/Microsoft, 2183 chars, 20-Oct-92 00:03:37 Fm: Bruce Ramsey/Microsoft 70324,2742 To: Guy Eddon 71172,1014 (X) ------------------------------------------------------------------------ Microsoft LAN Manager 2.0 and 2.1 servers used to be licensed to allow 10 client machines to attach, and then additional user packs could be used to increase the number of users a server could support With Windows NT and the recently announced LAN manager 2.2, servers support as many licensed client machines as you have licensed on your network ------------------------------------------------------------------------ OK, here's the question: what's the licensing position going to be if there are clients on the network that aren't supplied directly from Microsoft, for example DEC Pathworks clients. At the moment DEC insist that every cleint on the net that is going to access a Vax server must be licensed for Pathworks. Are you also going to insist that of the client is going to access an NT server, it must be licensed for Microsoft LAN Manager? thanks William There is 1 Reply. #: 15657 S1/NonTech Cust. Serv. 22-Oct-92 17:31:26 Sb: #15558-Lan Manager licensing Fm: Jerry Drain [Microsoft] 72350,2056 To: William Lees 75300,250 (X) Hi William, Let me answer you real generally, since I'm not in the sales or legal departments. If you need more information, you might try the MSNET forum, or wait for a couple of days and ask your question again when some of the regulars get back to our office (some of them are out of town right now). << OK, here's the question: what's the licensing position going to be if there are clients on the network that aren't supplied directly from Microsoft, for example DEC Pathworks clients. At the moment DEC insist that every cleint on the net that is going to access a Vax server must be licensed for Pathworks. Are you also going to insist that of the client is going to access an NT server, it must be licensed for Microsoft LAN Manager?>> As I understand it, the answer is no. If you are going to install for instance a DOS LanMan client package, and you need to install for x number of machines; well then you need to buy x number of licenses. However, if you already have a client that will talk to an NT server, you do not have to purchase a license to allow it to. Thanks, -- Jerry [@Microsoft] There is 1 Reply. #: 15718 S1/NonTech Cust. Serv. 23-Oct-92 15:29:54 Sb: #15657-Lan Manager licensing Fm: William Lees 75300,250 To: Jerry Drain [Microsoft] 72350,2056 Jerry, Thanks for your reassurance and advice. I'll ask the question again in MSNET next week. William #: 15728 S1/NonTech Cust. Serv. 23-Oct-92 19:47:27 Sb: Oct Win32SDK Docs Fm: John Reece 70153,2077 To: Sysop Just received the new Oct/92 Win32 SDK, and all is well with one exception. The 'Release Notes - October 1992' manual is so physically mangled as to be unusable. The pages are all bound together across the top, and the bottom is cut off at an angle, such that the bottom 1/4 of each page is missing. Clearly, QC missed this one... Is there any way for me to get another copy of this manual ? I don't need new disks/CD's, just the manual. If it helps, the packing list details are: Ship Date: 21-Oct-92 Pkg. ID: 335010719A2 Ship To: Reece, John 1567 Willard St., Apt. B San Francisco, CA 94117 If you need more info, let me know ... I have posted this message in section 1 of both MSWIN32 and WINNT. Thanks, John #: 15329 S2/SDK-MSTOOLS Setup 18-Oct-92 07:56:18 Sb: UK Keyboard Fm: Keith MacDonald 100041,235 To: SYSOP (X) When I run a DOS program, such as CIM the layout of my UK keyboard is not recognised. It is handled at the DOS command prompt correctly. Is there anything I can do to fix this? Thanks in advance, Keith #: 15346 S2/SDK-MSTOOLS Setup 19-Oct-92 04:28:44 Sb: Chinon CD Rom ignore Fm: Lee Hart [Microsoft] 76150,2536 To: Randy Subers 72707,1040 It sounds like your SCSI card is not supported by Windows NT. Double check that your controller appears on the Hardware Compatibility List (0992hw.txt) and for further information please followup to the WINNT forum, Section 3 'Windows NT Setup'. (Supported hardware is not a SDK question, it's an operating system question.) Lee Microsoft Developer Support #: 15389 S2/SDK-MSTOOLS Setup 19-Oct-92 15:18:56 Sb: #15276-"ostream.h" and cl386... Fm: Paul Tissue [Microsoft] 70744,24 To: Bill Cheng 75460,32 Hello Bill, OSTREAM.H did not make it into the July release. It is included with the October release that you should be getting really soon now. - Paul, Win32 SDK Developer Support #: 15318 S2/SDK-MSTOOLS Setup 17-Oct-92 13:18:24 Sb: #15290-NT debuging Kernal infor Fm: Jake Kirk 76207,1403 To: Peter G. Johansson 71023,557 (X) Peter. Do you really mean "DDK"? Is it not also documented in the "SDK"? If it is only documented in the DDK then how can I get these release notes? Are the release notes posted here? (How about it MS? are you listening?, could these be made up in a tech ref notes?). Does this mean I need to get the DDK CDROM? Thanks, //Jake. #: 15345 S2/SDK-MSTOOLS Setup 19-Oct-92 04:28:39 Sb: #15288-NT debuging Kernal infor Fm: Lee Hart [Microsoft] 76150,2536 To: Jake Kirk 76207,1403 (X) >How do I get the debugging kernal to give me some useful information? To run a kernel debugger you need to have a second machine running Windows NT. This is documented on page 310 of Chapter 7 of the Tools manual. Please disregard the section on the stand alone kernel debugger, as this functionality is no longer available. You may find that the kernel debugger is not quite what you are expecting. WinDbg should provide you with all of the functionality that you will need (particularly in upcoming releases) and the kernel debugger is aimed at DDK customers more than SDK customers. (In fact the closest thing to the debug libraries of Windows development is only available in the DDK - /NODEBUG in boot.ini only refers to the kernel debugger, not to the availability of debugging information.) For more information on the kernel debugger please go to Section 7, Tools-Microsoft. Lee Microsoft Developer Support There is 1 Reply. #: 15376 S2/SDK-MSTOOLS Setup 19-Oct-92 12:52:59 Sb: #15345-NT debuging Kernal infor Fm: Jake Kirk 76207,1403 To: Lee Hart [Microsoft] 76150,2536 (X) Thanks for the reply Lee, It will be nice to get the new WinDbg. But I am still not clear on what the /NODEBUG switch is actually doing or what if refers to. What does it imply? Thanks, //Jake. There is 1 Reply. #: 15391 S2/SDK-MSTOOLS Setup 19-Oct-92 15:19:07 Sb: #15376-NT debuging Kernal infor Fm: Paul Tissue [Microsoft] 70744,24 To: Jake Kirk 76207,1403 (X) Hello Jake, The /NODEBUG switch found in BOOT.INI disables portions of the built-in kernel debugger that pose problems when a debug terminal (another Windows NT machine) is not attached. For example, if the system generates an assert, the user must interact with the debug terminal to continue execution otherwise the system will remain halted. With the /NODEBUG switch, the system does an automatic 'continue' operation is this occurs. The services provided by the kernel debugger are only useful to those writing device drivers and other system services. Most of the features found in the Windows 3.1 kernel debugger are available to the application developer via WinDebug thus those using the kernel debugger would only gain unnecesary information at the cost of performance degradation. - Paul, Win32 SDK Developer Support #: 15396 S2/SDK-MSTOOLS Setup 19-Oct-92 16:23:23 Sb: #15221-oldnames gone in winnt Fm: Eric Sassaman/Microsoft 75430,411 To: Nicholas Duane 71044,1076 << We are porting our windows 3.0 application to windows nt and the linker keeps complaining "Oldnames.lib" does not exist. We read the help file and it said the we can use the "oldnames.lib" to keep our code compatible with unix. We can not find old names. >> Oldnames.lib is not supplied with the SDK. You need to stop linking with oldnames.lib to avoid this error message. I'm not sure which helpfile you are referring to, but it may be that this is old information, possibly from the C7 product, that was mistakenly not removed. If you can forward where you found this info, I'll make sure that it is corrected. For more information on oldnames.lib, please followup in section 7, MS tools. Eric Sassaman Microsoft NT Support #: 15416 S2/SDK-MSTOOLS Setup 19-Oct-92 20:50:34 Sb: #15221-oldnames gone in winnt Fm: Eric Sassaman/Microsoft 75430,411 To: Nicholas Duane 71044,1076 << The linker keeps complaining "Oldnames.lib" does not exist. >> Nicholas, the help file you were reading was definitely in error; there are no plans to supply a version of oldnames.lib with the SDK nor with any C language product for NT. Eric Sassaman Microsoft NT Support #: 15443 S2/SDK-MSTOOLS Setup 20-Oct-92 07:13:57 Sb: Which CD-ROM for WIN32? Fm: Mark Gibbons 76216,1032 To: all Now that the CD's have started arriving, I need to decide what CD drive meets my needs and has the most bang per buck. Does anyone have an opinion on the Chinon drive available by special offer in the WIN32 CD package? The Sound Blaster CD-ROM drive kit includes a 380 ms drive that is controlled by the Sound Blaster card included, all for around $299 street price. Is 380 ms fast enough for using the SDK? What are other people using, and are you happy with it? Any advice is appreciated. Mark #: 15495 S2/SDK-MSTOOLS Setup 20-Oct-92 19:31:15 Sb: #15443-Which CD-ROM for WIN32? Fm: Eric Sassaman/Microsoft 75430,411 To: Mark Gibbons 76216,1032 (X) << Now that the CD's have started arriving, I need to decide what CD drive meets my needs and has the most bang per buck. Does anyone have an opinion on the Chinon drive available by special offer in the WIN32 CD package? The Sound Blaster CD-ROM drive kit includes a 380 ms drive that is controlled by the Sound Blaster card included, all for around $299 street price. Is 380 ms fast enough for using the SDK? What are other people using, and are you happy with it? Any advice is appreciated. >> Mark, you might also want to ask around in the WINNT forum, perhaps in section 3 (NT setup) or 8 (hardware compatibility) - you might get some good opinions there as well. Eric Sassaman Microsoft NT Support #: 15507 S2/SDK-MSTOOLS Setup 21-Oct-92 07:11:59 Sb: #15443-Which CD-ROM for WIN32? Fm: Arthur Knowles 71041,2613 To: Mark Gibbons 76216,1032 (X) mark, <> If you mean the CD technology offer, that's a Toshiba CD-ROM drive. As to a recommendation I'll tell you two things... 1) Do not consider any non SCSI-2 CD-ROM drives. I say thins beacuse currently only SCSI-2 CD-ROM drives will play audio CD's under NT. This may change later. Also do not consider any proprietary CD-ROM drives. No IDE or other propietary (SoundBlaster) interfaces. Only SCSI CD-ROM drives are curretnly supported. 2) Make sure you get a SCSI adapter which is supported. Look at the hardware compatability list to verify that the SCSI card is supported. If you can get a 16 bit SCSI card that can use high end IRQs. NT cannot share IRQs on an ISA bus. If you do not mind waiting 6 months for a driver. You might consider the MM upgrade kits. Some have SCSI-2 CD-ROM drives. Some do not. The Media Vision Pro-16 currently is being shipped with the NEC drives. They are not SCSI-2 complient, but MV has mentioned that NT drivers will be made available by years end. That might include a filter driver to convert the SCSI-2 command set to the NEC audio commands. You could ask MV about it in the MULTIVEN forum, section 12. Art #: 15634 S2/SDK-MSTOOLS Setup 22-Oct-92 14:53:55 Sb: Asm / C var sharing Fm: Fred Schempp 70421,1262 To: All I am having trouble locating information on declaring shared variables between c and assembly files. Could anyone supply me with a resource or an example asm / c file set. Thanks #: 15727 S2/SDK-MSTOOLS Setup 23-Oct-92 19:03:53 Sb: ULTRASTOR Fm: ROBERT ROBINSON 71076,226 To: ALL IS A DRIVER AVAILABLE YET FOR THE ULTRASTOR 24F 32 BIT SCSI CONTROLLER - FOR ACCESS TO A CD-ROM THANK YOU. ROBERT ROBINSON #: 15445 S3/SQL Svr SDK (WINNT) 20-Oct-92 08:02:14 Sb: #15283-SQLServer/NT/WIN16 Fm: Joe Marler 71075,416 To: Oscar M. Herrera 71174,1204 I'll look into this and get back to you. It should work. If I haven't responded in about 2 days, email me as a reminder. -- Joe Marler #: 15515 S3/SQL Svr SDK (WINNT) 21-Oct-92 09:21:10 Sb: #15445-SQLServer/NT/WIN16 Fm: John Stoddard 72400,2551 To: Joe Marler 71075,416 (X) I am quite curious about this too. I have an application that uses ODS, and thus looks just like SQL Server, running under Win32. I can connect fine from the NT version of ISQL, but the OS/2 version tells me it can't find the named pipe. Also, 16-bit Windows applications that use dblib give the same message - SQL Server Not Found. It would seem that programs running under the non-native subsystems can't connect to named pipes published by win32 apps... or, maybe there's some setup magic I don't know about... John Stoddard Micro Decisionware There is 1 Reply. #: 15600 S3/SQL Svr SDK (WINNT) 22-Oct-92 09:37:01 Sb: #15515-SQLServer/NT/WIN16 Fm: Joe Marler 71075,416 To: John Stoddard 72400,2551 Oscar and John - DOS, Win16, and OS/2 DB-Lib apps generally don't work on the July Windows NT SDK. This release was of course targeted primarily at Win32 developers. The good news is that the October beta 1 relase of Windows NT is now shipping (as of yesterday) to all registered SDK users. I have tested DOS, Win16 and OS/2 DB-Lib apps on this release, and they all work. You will likely be pleasantly surprised at the overall improvements in this area. Unfortunately, you must manually install the 4.2 OS/2 version of SQL Server on this release of Windows NT. We are working to correct this. I will email you both a document that describes this manual installation procedure. Joe Marler #: 15679 S3/SQL Svr SDK (WINNT) 23-Oct-92 08:12:06 Sb: SQL 4.2 Install on WinNT Fm: James McDaniel [MS] 71075,415 To: all I posted the file SQLOS2.TXT in section 3 (SQL Srv SDK) of the Library. This text file is a section from the SQL Server SDK for Windows NT release notes. It states that installing SQL Server for OS/2 version 4.2 on the OS/2 subsystem of the July pre-release of Windows NT often fails, and it contains a "manual install" procedure for completing the install by hand. Sincerely, James McDaniel Microsoft SQL Server Support #: 15369 S4/API-User Interface 19-Oct-92 11:22:45 Sb: #15286-LoadResource return val Fm: Paul Tissue [Microsoft] 70744,24 To: neil colvin 71650,3517 (X) Hello Neil, Please download the file DLGFMT.ZIP for library 4. This may be what you are looking for. - Paul, Win32 SDK Developer Support #: 15380 S4/API-User Interface 19-Oct-92 13:31:21 Sb: #15243-dynamic icon changes Fm: Paul Tissue [Microsoft] 70744,24 To: Ralph Smith 76376,3150 (X) Hello Ralph, I concur that it does seem logical to simply set a new class icon and invalidate the rectangle. I have escalated this issue to development. I'll let you know what I find out. - Paul, Win32 SDK Developer Support #: 15444 S4/API-User Interface 20-Oct-92 07:28:11 Sb: iostream.h on NT Fm: Christian Betrisey 76600,1450 To: 72350,2635 (X) Where is the header file "iostream.h" located ? Thanks, Nick There is 1 Reply. #: 15468 S4/API-User Interface 20-Oct-92 12:53:31 Sb: #15444-iostream.h on NT Fm: Paul Tissue [Microsoft] 70744,24 To: Christian Betrisey 76600,1450 (X) Hello Nick, IOSTREAM.H did not make it into the July release. It is in the October release that will be out very soon now. Thank you. - Paul, Win32 SDK Developer Support #: 15440 S4/API-User Interface 20-Oct-92 06:32:14 Sb: System object limits Fm: Mark L Hornick 70413,1717 To: Microsoft Can anyone tell me whether NT imposes any limits on the number of threads that are allowed under one process, or the number of semaphores that one process can create? We are porting a large industrial control application from UNIX to NT that requires 30 threads under one process and about 100 semaphores. Thanks. Mark Hornick There is 1 Reply. #: 15469 S4/API-User Interface 20-Oct-92 12:53:35 Sb: #15440-System object limits Fm: Paul Tissue [Microsoft] 70744,24 To: Mark L Hornick 70413,1717 (X) Hello Mark, I do not know what the exact limits for the maximum number of threads and semphores is per process but I do know that these number are _very_ large and the upper bounds you mention are no problem. Please ask the folks in section 6: "API-Base/Security" for the exact limits and they will be happy to look into it. - Paul, Win32 SDK Developer Support There is 1 Reply. #: 15477 S4/API-User Interface 20-Oct-92 13:50:20 Sb: #15469-System object limits Fm: Mark L Hornick 70413,1717 To: Paul Tissue [Microsoft] 70744,24 Paul, Thanks for the info. The reason I was asking is that the defaults are rather meager in the version of UNIX that we are porting from; you have to rebuild the kernel in order to increase them. Mark Hornick #: 15433 S4/API-User Interface 20-Oct-92 04:32:17 Sb: Common Dialogs and Win32 Fm: Wim Bonner 72561,3135 To: Microsoft Common Dialogs wih the July pre-release? I want to know if anyone has had problems with the common dialog boxes in the July release of Windows NT? I am using the Openfile box, and everything is set up exactly as I have set up for using windows 3.1. Under the Files of Type combo box, it lists the correct thing as the default extension, but it doesn't properly use the default Extension to fill the box with possible file names. Also, my string that I pass for that entry includes an entry for All Files with *.* as the filspec, but that entry doesn't show up at all. I I manually go into the file selection editbox and add *.* it lists the files and hands back the right stuff to my program, but it seems to be missing out on the setup of the dialog box. What should I be looking for? #: 15522 S4/API-User Interface 21-Oct-92 12:22:38 Sb: #15433-Common Dialogs and Win32 Fm: Bob Landau [Microsoft] 70744,21 To: Wim Bonner 72561,3135 (X) Wim, I just tried a sample of mine on the PDC build it does work for ASCII strings. The OPENFILENAME structure did not support UNICODE in that build; it does now. As for suggestions about all I can offer is double check that the fields in OPENFILENAME are initialized correctly. In particular lpstrFile must either be NULL or point to a asciiz string and lpstrFilter must contain NULL terminated filters and have 2 NULL charactors at the end. i.e. "C files\0*.c\0All Files\0*.*\0\0 If neither of these suggestion point to the problem I can either send you my sample or you could get a similar sample off the CD ( \Q_A\SAMPLES\CMNDLG ) Microsoft Developer Support Bob Landau #: 15373 S4/API-User Interface 19-Oct-92 12:06:50 Sb: WaitMessage and DDEML Fm: Bill Baker 76300,2150 To: sysop (X) We're having a problem with WaitMessage and DDEML. We have a 16-bit app talking to a 32-bit app using DDEML. We use WaitMessage in our 32-bit app (which acts like a server) to stop spinning when we're not doing anything. This server app was ported to NT from UNIX, so the command processing is not geared towards a Get/Dispatch Message loop; to make a long story short, we need WaitMessage. The problem occurs with the first DDEML transaction from the 16-bit app to the 32-bit app. Nothing happens until we put the cursor over the server app (iconizied). In other words, the first time through, it seems as if the DDEML transaction is not enough to wake up the app; it takes a mouse move message, and then everything works fine. Any ideas, solutions, suggestions would be GREATLY appreciated. We under a tight schedule for a demo. There is 1 Reply. #: 15382 S4/API-User Interface 19-Oct-92 13:51:01 Sb: #15373-WaitMessage and DDEML Fm: Paul Tissue [Microsoft] 70744,24 To: Bill Baker 76300,2150 (X) Hello Bill, There are some known problems with DDE between Win16 and Win32 applications in the July release. This may be the cause of the problem. The October release has fixed all known Win16 <-> Win32 DDE problems. Please check this on the October release when it arrives. Also, how are you updating the mimimized icon? You may want to follow the "dyanamic icon changes" thread in this section (starts with message #15047). Currently this situation is being looked into but in the meantime I posted one method which does work correctly for updating the icon. - Paul, Win32 SDK Developer Support There is 1 Reply. #: 15442 S4/API-User Interface 20-Oct-92 07:06:21 Sb: #15382-WaitMessage and DDEML Fm: Bill Baker 76300,2150 To: Paul Tissue [Microsoft] 70744,24 (X) This problem still exists in the special pre-release of the October beta (which we received because of our participation in the porting lab). Any other suggestions? Thanks... #: 15543 S4/API-User Interface 21-Oct-92 14:03:44 Sb: #15442-WaitMessage and DDEML Fm: Paul Tissue [Microsoft] 70744,24 To: Bill Baker 76300,2150 Hello Bill, Attempting to write a Windows program without using the standard Dispatch message loop is a bit out of my league; the issues and problems that can result from this are unknown to me. Do you have a small sample which reproduces the problem you are seeing? Have you used SPY and DDESPY to determine if the application is really getting the DDE notification? The WaitMessage API will suspend the thread until a new message is received in the queus. If, for some reason, the DDE notification is not getting into the thread's message queue then the mouse event surely will "wake-up" the thread. Either way, it is not clear whether this is a problem the Win32 subsystem or your application. Sample code would surely help to pin point the fault. - Paul, Win32 SDK Developer Support #: 15523 S4/API-User Interface 21-Oct-92 12:23:26 Sb: error from cvpack Fm: Christian Betrisey 76600,1450 To: 72350,2635 (X) When I compile and link a C++ program, I got the following error (linker) messages: CVPACK: Fatal error, ek1001: out of memory. CVPACK::Warning ckc001: file already packed. Could you tell me what the problem was ? Nick There is 1 Reply. #: 15565 S4/API-User Interface 21-Oct-92 16:49:18 Sb: #15523-error from cvpack Fm: Bob Landau [Microsoft] 70744,21 To: Christian Betrisey 76600,1450 (X) Nick, Please post this in the tools section MS2WIN32 section 7. When you re-post this please let us know a little more about the build process such as 1) Size of C++ file 2) Is this a MFC application or Windows 3) Are you basing the makefile on NTWIN32.MAK 4) CVPACK is really only used for WinDbg which did not support C++ source debugging in the July release you should be able to remove this entirely without causing any problems running this. Microsoft Developer Support Bob Landau #: 15677 S4/API-User Interface 23-Oct-92 07:04:10 Sb: SetWindowsHook Bug Fm: Keith MacDonald 100041,235 To: SYSOP (X) It's possible to abort any process on the system, that accepts keyboard input in a dialog box, by running a program that makes the following call: hHook = SetWindowsHookEx(WH_KEYBOARD, (HOOKPROC)&kbdproc, hInstance, 0); and then activating the program you want to abort (such as winhelp or winfile) and typing one character in one of its dialog boxes. The manual states that this use of SetWindowsHook is only valid in a DLL, but nothing stops you from actually doing it in an application. I hit upon this problem in converting a C++ application from Windows 3.1. I couldn't get it's DLL working due to a bug in LIB.EXE, so I merged it into the .EXE file. The solution is to set the 3rd argument to NULL, and the 4th to GetCurrentThreadId(), but CAPS LOCK and NUM LOCK don't get propagated as intended by doing this. There is 1 Reply. #: 15693 S4/API-User Interface 23-Oct-92 11:06:33 Sb: #15677-SetWindowsHook Bug Fm: Bob Landau [Microsoft] 70744,21 To: Keith MacDonald 100041,235 Keith, You're right SetWindowsHookEx() should not behave like this. Can you please answer the following info 1) hHook is not null right? 2) You're using CallNexHookEx() right? 3) What is your hook procedure doing/returning? 4) Have you tried this on the Oct release? Microsoft Developer Support Bob Landau There is 1 Reply. #: 15706 S4/API-User Interface 23-Oct-92 11:55:22 Sb: #15693-SetWindowsHook Bug Fm: neil colvin 71650,3517 To: Bob Landau [Microsoft] 70744,21 (X) You keep asking people if they have tried things on the october release. I have yet to hear from one person who I know with the WINNT SDK who has the October release. I guess someone must, or you wouldn't ask. When will the majority of us get it (especially the 4000 of us who went to the PDC)??? #: 15710 S4/API-User Interface 23-Oct-92 12:49:55 Sb: DDE Fm: Howard Myers 76711,462 To: Microsoft I set up a DDE_ADVISE in my app. on the Count variable of the DDE Server Sample Appl. A c0000005 (Access Violation) is generated in WinDbg when I actually get advised of the change. The following sequence of messages were captured with DDESpy when receiving the sequence that caused the problem: ask: 0x4c Time: 7255470 Callback: Type=Advreq, fmt=0x1("CF_TEXT"), hConv=0x7c02200, hsz1=0xc002("Test") hsz2=0xc001("Count"), hData=0x0, dwData1=0x0, dwData2=0x0 return=0x8c03600 Output data= "4" ... ask: 0x4c Time:7255485 hwndTo=0xb00f8 Message(Posted)=Data: hwndFrom=0x90094, status=a000(fRelease ) fmt=0x1("CF_TEXT") Data= "4" Item=0xc00a("Count") ask:0x87 Time:7255500 Callback: Type=Advdata, fmt=0x1("CF_TEXT"), hConv=0x801300, hsz1=0xc001("Test") hsz2=0xc002("Count"), hData=0x1802600, dwData1=0x0, dwData2=0x0 return=0x8000 Input data= "4" ... The call trace from WinDbg appears as follows: _CISpontAdviseData@8 _SpontaneousClientMessage@12 _ProcessSyncDDEMessage@12 _ProcessAsyncDDEMsg@16 _DDEMLClientWndProc@16 _DispatchMessageWorker@8 _DispatchMessageA@4 MyAppsRoutine() .. My code is simply doing the following at this point: GetMessage(&msg,NULL,0,0); TranslateMessage(&msg); DispatchMessage(&msg); This code works under 3.1 and under the July release. This problem (and unfortunately many others) just started with the October Beta release. [more] There is 1 Reply. #: 15711 S4/API-User Interface 23-Oct-92 12:51:12 Sb: #15710-DDE Fm: Howard Myers 76711,462 To: Howard Myers 76711,462 (X) A similar problem happens when I try to connect the Client sample to my application (again, this worked under 3.1 and with the July release). I get the same exception and the DDESpy dump for the last couple of messages is: Task:0x5b Time:3458655 hwndTo=0x240108 Message(Sent)=Initiate: hwndFrom=0x1b0173, App=0xc009("PW") Topic=0x0("#0") Task:0x4c Time:3458670 Callback: Type=Wildconnect, fmt=0x0("?"), hConv=0x0, hsz1=0x0("") hsz2=0xc000("PW"), hData=0x0, dwData1=0x0, dwData2=0x0 return=0x400600 Output data= 00 c0 00 00 02 c0 00 00 00 c0 00 00 00 00 00 00 ........... ..... There are a number of Similar messages to the Initiate: listed above immediately preceding it. They are identical except for the time and hwndTo fields. The Call Trace in this case is: __ClientDDEMLInitiateServers@24 ___ClientDDEMLInitiateServers@4 _CsrpProcessCallbackRequest@4 _CsrClientSendMessage@0 _CCSMakeCall@4 _ServerGetMEssage@20 _GetMessageA@16 This happens during the same GetMessage() call shown above. The DDEML Client Sample generates a dialog box with the following: DDEML Error-No_conv_established Any ideas on these problems? I can get the Server and Client apps. to talk to each other, but my app. that worked with the July release is totally hosed now. #: 15674 S4/API-User Interface 23-Oct-92 06:34:14 Sb: DLGTEMPLATE structure Fm: Malinda Adams 72410,412 To: Microsoft I am trying to find some correct documentation on the DLGITEMTEMPLATE and the DLGTEMPLATE structures. In the pre-release doc (Programmer's Reference: API Part 2 - pages 721-723), there is no description of the fields for the DLGITEMTEMPLATE structure and the description for the DLGTEMPLATE fields does not match the structure. Thanks for any help. Malinda Adams There is 1 Reply. #: 15716 S4/API-User Interface 23-Oct-92 14:03:46 Sb: #15674-DLGTEMPLATE structure Fm: Steve Firebaugh [MS] 75430,412 To: Malinda Adams 72410,412 Malinda Adams. Please try downloading the file DLGFMT.ZIP from library 4. I believe it contains the information that you are looking for. Steve Firebaugh #: 15478 S5/API-GDI/Graphics 20-Oct-92 14:07:38 Sb: #15265-Metafiles from clipboard Fm: Petrus Wong [Microsoft] 70743,3355 To: Howard Myers 76711,462 (X) Hi Howard: Here is some code that works... case MM_COPY: { #ifndef W3X_FORMAT if (ghMetaf == 0) { SetWindowText(ghTextWnd, "No Metafile for copying"); return 0L; } #else if (ghmf == 0) { SetWindowText(ghTextWnd, "No Metafile for copying"); return 0L; } #endif OpenClipboard(ghwndMain); EmptyClipboard(); #ifndef W3X_FORMAT { HENHMETAFILE hEmfTmp; hEmfTmp = CopyEnhMetaFile(ghMetaf, NULL); if (hEmfTmp) { SetClipboardData(CF_ENHMETAFILE, hEmfTmp); DeleteEnhMetaFile(hEmfTmp); } } #else { HGLOBAL hmem; LPMETAFILEPICT lpmfp; RECT rcClientDS; DWORD x, y, mm; HDC hDCDrawSurf; if ((hmem = GlobalAlloc(GMEM_ZEROINIT | GMEM_MOVEABLE | GMEM_DDESHARE, sizeof(METAFILEPICT))) == NULL) { SetWindowText(ghTextWnd, "Failed in allocating memory"); goto COPY_EXIT; } hDCDrawSurf = GetDC(ghwndDrawSurf); lpmfp = (LPMETAFILEPICT)GlobalLock(hmem); lpmfp->mm = mm = MM_ANISOTROPIC; GetClientRect(ghwndDrawSurf, &rcClientDS); x = rcClientDS.right - rcClientDS.left; x *= 2540; x /= GetDeviceCaps(hDCDrawSurf, LOGPIXELSX); lpmfp->xExt = x; y = rcClientDS.bottom - rcClientDS.top; y *= 2540; y /= GetDeviceCaps(hDCDrawSurf, LOGPIXELSY); lpmfp->yExt = y; [More] There is 1 Reply. #: 15479 S5/API-GDI/Graphics 20-Oct-92 14:07:52 Sb: #15478-Metafiles from clipboard Fm: Petrus Wong [Microsoft] 70743,3355 To: Petrus Wong [Microsoft] 70743,3355 [Continued] lpmfp->hMF = CopyMetaFile(ghmf, NULL); GlobalUnlock(hmem); SetClipboardData(CF_METAFILEPICT, hmem); ReleaseDC(ghwndDrawSurf, hDCDrawSurf); } COPY_EXIT: #endif CloseClipboard(); return 0L; } case MM_PASTE: { OpenClipboard(ghwndMain); #ifndef W3X_FORMAT { HENHMETAFILE hEmfTmp; ENHMETAHEADER EnhMetaHdr; hEmfTmp = GetClipboardData(CF_ENHMETAFILE); if (hEmfTmp) { DeleteEnhMetaFile(ghMetaf); ghMetaf = CopyEnhMetaFile(hEmfTmp, NULL); DeleteEnhMetaFile(hEmfTmp); GetEnhMetaFileHeader(ghMetaf, sizeof(EnhMetaHdr), &EnhMetaHdr); SetDlgItemInt(ghwndCtrlPanel, DID_COUNTER, EnhMetaHdr.nRecords, FALSE); bReset = TRUE; } } #else { HANDLE hmem; DWORD dwXSugExt, dwYSugExt, dwMM; HDC hDCDrawSurf; RECT rc; INT iSavedDC; hmem = GetClipboardData(CF_METAFILEPICT); if (hmem) { LPMETAFILEPICT lpmfp; lpmfp = (LPMETAFILEPICT)GlobalLock(hmem); ghmf = lpmfp->hMF; dwMM = lpmfp->mm; dwXSugExt = lpmfp->xExt; dwYSugExt = lpmfp->yExt; GlobalUnlock(hmem); hDCDrawSurf = GetDC(ghwndDrawSurf); iSavedDC = SaveDC(hDCDrawSurf); GetClientRect(ghwndDrawSurf, &rc); SetMapMode(hDCDrawSurf, dwMM); if (dwXSugExt && dwYSugExt) { DWORD x; DWORD y; x = dwXSugExt; [More] There is 1 Reply. #: 15480 S5/API-GDI/Graphics 20-Oct-92 14:08:03 Sb: #15479-Metafiles from clipboard Fm: Petrus Wong [Microsoft] 70743,3355 To: Petrus Wong [Microsoft] 70743,3355 [Continued] x *= GetDeviceCaps(hDCDrawSurf,LOGPIXELSX); x /= 2540; // inch/millimeter y = dwYSugExt; y *= GetDeviceCaps(hDCDrawSurf,LOGPIXELSY); y /= 2540; // inch/millimeter SetWindowExtEx(hDCDrawSurf, x, y, NULL); } else { SetWindowExtEx(hDCDrawSurf, rc.right, rc.bottom, NULL); } SetViewportExtEx(hDCDrawSurf, rc.right, rc.bottom, NULL); SetViewportOrgEx(hDCDrawSurf, 0, 0, NULL); SetWindowOrgEx(hDCDrawSurf, 0, 0, NULL); PlayMetaFile(hDCDrawSurf, ghmf); RestoreDC(hDCDrawSurf, iSavedDC); ReleaseDC(ghwndDrawSurf, hDCDrawSurf); } } #endif CloseClipboard(); EnableMenuItem(hMenu, MM_COPY, MF_ENABLED); return 0L; } petrus... There is 1 Reply. #: 15484 S5/API-GDI/Graphics 20-Oct-92 14:38:49 Sb: #15480-Metafiles from clipboard Fm: Howard Myers 76711,462 To: Petrus Wong [Microsoft] 70743,3355 Petrus, Thanks for the info. I'll give it a try on Thursday when I'm back in the office. Thanks again! Howard Myers #: 15349 S5/API-GDI/Graphics 19-Oct-92 06:40:05 Sb: BITMAP sample Fm: Paul Ligeski 76636,1166 To: Sysop (X) Hi, In both the 3.0 and the 3.1 SDK there was a sample program called BITMAP which showed how to use BitBlt. Is there a BITMAP for NT? I ask because the previous SDK samples used LoadBitmap with a string. Under NT, I have to assign a #define statement to the symbol in the resource file and use MAKEINTRESOURCE in the code. This is kinda cumbersome since I was previously displaying the string name of the current resource. --Paul There is 1 Reply. #: 15409 S5/API-GDI/Graphics 19-Oct-92 18:08:45 Sb: #15349-BITMAP sample Fm: Petrus Wong [Microsoft] 70743,3355 To: Paul Ligeski 76636,1166 Hello Paul: >>In both the 3.0 and the 3.1 SDK there was a sample program called BITMAP which showed how to use BitBlt. Is there a BITMAP for NT?<< No, there is a similar sample called "Streblt" in the Q_A directory on the CD. >>I ask because the previous SDK samples used LoadBitmap with a string. Under NT, I have to assign a #define statement to the symbol in the resource file and use MAKEINTRESOURCE in the code. This is kinda cumbersome since I was previously displaying the string name of the current resource.<< Check out the "Streblt" sample, it calls the LoadIcon() API as follows: LoadIcon(hInstance, "strebltIcon"); In the RC file, the resource is defined as: strebltIcon ICON streblt.ico thanks, petrus #: 15511 S5/API-GDI/Graphics 21-Oct-92 09:05:40 Sb: #15409-BITMAP sample Fm: Paul Ligeski 76636,1166 To: Petrus Wong [Microsoft] 70743,3355 (X) Hi Petrus, Thanks for directing me to the StreBlt sample in the Q_A area. I didn't get that far. --Paul P.S. Is this on the October release as well and do you know if I should be getting that soon? (today's 10/21/92) There is 1 Reply. #: 15577 S5/API-GDI/Graphics 21-Oct-92 21:34:05 Sb: #15511-BITMAP sample Fm: Petrus Wong [Microsoft] 70743,3355 To: Paul Ligeski 76636,1166 (X) Hi Paul: >>P.S. Is this on the October release as well and do you know if I should be getting that soon? (today's 10/21/92)<< Yes, it is also on the October release. Well, everybody on this program will be getting the release. But, it is hard to say how long does it take to get to your place. thanks, petrus #: 15353 S5/API-GDI/Graphics 19-Oct-92 08:13:35 Sb: #15268-Making .FON files Fm: Howard Myers 76711,462 To: Steve Firebaugh [MS] 75430,412 (X) Steve, Thanks for your pro-active help on this. Your strategy makes a lot of sense. Howard Myers #: 15482 S5/API-GDI/Graphics 20-Oct-92 14:36:18 Sb: #15268-Making .FON files Fm: Howard Myers 76711,462 To: Steve Firebaugh [MS] 75430,412 Steve, I received the October release yesterday and installed it today. So, anytime you can upload the font building procedure for this release, it would be greatly appreciated! Thanks! Howard Myers #: 15489 S5/API-GDI/Graphics 20-Oct-92 15:43:32 Sb: #15482-Making .FON files Fm: Jeong Ho Lee 70253,1244 To: Howard Myers 76711,462 (X) >> I received the Oct release yesterday .... PMJI, are you a kind of special developer ? Or an ordinary SDK owner or SF conference attendee ? Can I expect that I will receive it tomorrow ? ;-) Thabks jLee #: 15521 S5/API-GDI/Graphics 21-Oct-92 11:04:20 Sb: #15482-Making .FON files Fm: Steve Firebaugh [MS] 75430,412 To: Howard Myers 76711,462 (X) Howard, I just uploaded MAKFON.ZIP to library 5. Let me know if you have any problems with it. Steve Firebaugh There is 1 Reply. #: 15597 S5/API-GDI/Graphics 22-Oct-92 08:54:16 Sb: #15521-Making .FON files Fm: Howard Myers 76711,462 To: Steve Firebaugh [MS] 75430,412 (X) Steve, Thanks for being so prompt in uploading this... I'll give it a try! #: 15502 S5/API-GDI/Graphics 20-Oct-92 21:24:36 Sb: #15223-Enhanced Meta Files Fm: Petrus Wong [Microsoft] 70743,3355 To: Howard Myers 76711,462 (X) Hello Howard: >>...enhanced meta file. The entire meta file does appear properly in MFEDIT when pasted in. However, if I then copy it out to the clipboard, it seems to exhibit similar problems. << I've just tried to reproduce this on our beta build. The clipboard does seems to have no problem displaying the entire enhanced metafile (created by paintbrush as you described.) So, perhaps, it was a bug in either paintbrush or clipboard that has been fixed. Let us know again if you still have the same problem when you get your beta. thanks, petrus There is 1 Reply. #: 15631 S5/API-GDI/Graphics 22-Oct-92 14:39:16 Sb: #15502-Enhanced Meta Files Fm: Howard Myers 76711,462 To: Petrus Wong [Microsoft] 70743,3355 (X) Well Petrus, I got my beta and it's still the same. Specifically how I re-create it is to open paintbrush and load \winnt\winnt.bmp Next, I select the rectangular Cutting option. I select a rectangle that includes the entire flag icon plus some additional "gray" on each side. Next, I copy it to the clipboard. When I open the Clipboard Viewer, the bitmap and picture versions are fine. However, the enhanced metafile version is cut off just to the right of where the green and yellow squares start and at the bottom before the blue square ends. I definitely feel like it is either a paintbrush or clipboard problem, although I first discovered it when I tried to load it into my app. It's not that critical of a problem, but 1) thought you might want to know about it, and 2) it's hard to test this aspect of my app. without getting good metafiles on clipboard. #: 15633 S5/API-GDI/Graphics 22-Oct-92 14:43:15 Sb: #15223-Enhanced Meta Files Fm: Petrus Wong [Microsoft] 70743,3355 To: Howard Myers 76711,462 (X) Hello Howard: > from my last response to you... >I've just tried to reproduce this on our beta build. The clipboard does seems to have no problem displaying the entire enhanced metafile (created by paintbrush as you described.) So, perhaps, it was a bug in either paintbrush or clipboard that has been fixed.< I was playing around with paintbrush again this morning and this time I was able to reproduce the problem you mentioned. It does seem like paintbrush was not creating the metafile correctly. I am looking into this right now...I'll get back to you when I nail down the problem. thanks, petrus There is 1 Reply. #: 15675 S5/API-GDI/Graphics 23-Oct-92 06:35:27 Sb: #15633-Enhanced Meta Files Fm: Howard Myers 76711,462 To: Petrus Wong [Microsoft] 70743,3355 (X) Thanks. Look forward to hearing from you. #: 15332 S6/API-Base/Security 18-Oct-92 16:18:21 Sb: #15179-Timeslice Duration Fm: Ben Laurie 100014,1235 To: Eric Sassaman/Microsoft 75430,411 (X) Eric, << If the balance set manager sees that a process that it's been stealing pages from is incurring more page faults it will bump that process's working set size back up.>> I like it. An algorithm that recognises the S-shape of cache hits vs. cache size. My compliments to the chef. Ben. #: 15339 S6/API-Base/Security 19-Oct-92 03:57:14 Sb: NTFS data attrib size Fm: David A. Solomon 71561,3603 To: sysop sysop (X) An NTFS question: One of the performance features described at the July PDC was that if the data attribute of a file was small, it could fit with the other 'file header' information in the MFT and thus the entire file (header data as well as file data) could be accessed in a single I/O. The same was said to be true for small directory files (the index attribute fitting with the file header in the MFT record). What was not mentioned was the appx size of the data attribute that would fit... I realize this depends on the size of the other attributes (e.g. the file name, security description), which are variable length -- but, can you give a ballpark figure? #: 15361 S6/API-Base/Security 19-Oct-92 09:56:48 Sb: Thread "ON EXIT" Fm: Koby 71172,2722 To: Pete Grey [Microsoft] 70744,22 (X) Thanks Pete, I'll try to find a way to handle it. However it will be nice to let a thread to do some clean up work before it terminated by some one. Maybe you can consider it in the future API. Koby #: 15340 S6/API-Base/Security 19-Oct-92 03:57:21 Sb: HPFS on all platforms? Fm: David A. Solomon 71561,3603 To: sysop sysop (X) Someone recently mentioned they had heard that HPFS is only supported on Intel platforms -- my understanding was that it was supported on all NT hardware platforms... Could one of the MS folks confirm (or correct) this? Thanks... There is 1 Reply. #: 15364 S6/API-Base/Security 19-Oct-92 10:41:11 Sb: #15340-HPFS on all platforms? Fm: Pete Grey [Microsoft] 70744,22 To: David A. Solomon 71561,3603 (X) >> Someone recently mentioned they had heard that HPFS is only supported on Intel platforms -- my understanding was that it was supported on all NT hardware platforms... << Not true, I just formatted one of my MIPS' box drives to HPFS. 'Course you need to use NT format the drive as HPFS, unless you're going to remove the drive and move it to another machine. -pete #: 15342 S6/API-Base/Security 19-Oct-92 03:57:38 Sb: user-defined rights? Fm: David A. Solomon 71561,3603 To: sysop sysop (X) Is there any way for one to add their own rights to the list of valid user rights? I am trying to ascertain if NT provides something like the VMS user-defined identifiers, where the system manager can add named identifiers to the 'rights database' and then use those for security control in ACLs, etc. I suppose Groups in NT mimick the above capability in VMS, but wanted to ask this anyway... if you need more info on the VMS capability, I can provide more detail. Thanks! Dave Solomon There is 1 Reply. #: 15367 S6/API-Base/Security 19-Oct-92 11:01:12 Sb: #15342-user-defined rights? Fm: Pete Grey [Microsoft] 70744,22 To: David A. Solomon 71561,3603 (X) >> Is there any way for one to add their own rights to the list of valid user rights? I am trying to ascertain if NT provides something like the VMS user-defined identifiers, where the system manager can add named identifiers to the 'rights database' and then use those for security control in ACLs, etc. << It is definitely possible to assign access rights on a per-group basis to individual objects such as files, directories, etc. >> I suppose Groups in NT mimick the above capability in VMS, but wanted to ask this anyway... if you need more info on the VMS capability, I can provide more detail. << Not real familiar with the VMS stuff, but if the above didn't answer your question, please provide more info. -pete #: 15374 S6/API-Base/Security 19-Oct-92 12:07:21 Sb: RPC Fm: Koby 71172,2722 To: sysop (X) We are porting a distributed realtime system to WinNT and plan to use the built-in RPC (current version 1.0a) as the main communucation tool. 1. Apparently there is a mismatch between the on-line documentation and the implementation of RpcMgmtIsServerListening() function. When the server does not listen, the function returns RPC_S_SERVER_NOT_LISTENING (code 1738( rather then RPC_S_NOT_LISTENING (code 1715). 2. I wrote a prototype with two processes and bi-directional RPC connection (the reversed connection is to avoid the use of the callback mechanism). Let A, B denote the to processes and A.foo and B.bar two remote function exported by A and B respectively. I tried recursive call sequence in which A.foo calls B.bar which calls A.foo ... The sequence seems to hang up after a single call in each direction. Thanks Koby There is 1 Reply. #: 15385 S6/API-Base/Security 19-Oct-92 14:12:19 Sb: #15374-RPC Fm: Pete Grey [Microsoft] 70744,22 To: Koby 71172,2722 >> We are porting a distributed realtime system to WinNT and plan to use the built-in RPC (current version 1.0a) as the main communucation tool. << Please repost to section 12 API-RCP/WinNet. Thanks, -pete #: 15394 S6/API-Base/Security 19-Oct-92 16:03:51 Sb: Application Licencing Fm: Bruce Ramsey/Microsoft 70324,2742 To: Kenneth Nicolson 100113,304 (X) Hi Ken - Regarding your question on plans for serialization, we have no plans to provide a serial number unique to each copy of Windows NT which can be used in the ways you mentioned Bruce #: 15328 S6/API-Base/Security 18-Oct-92 07:56:12 Sb: Clobbering Memory Fm: Keith MacDonald 100041,235 To: SYSOP (X) Under what circumstances can one process overwrite the memory state of another? I have a program written using the MFC library which causes other processes to fail whilst it is running. In particular WINHELP and WINFILE both abort with the following dialog box message if I use them when my program is running: "The instruction at 0x0013108a referenced memory at 0x0013108a". The memory could not be "read". My program is not doing anything unusual (unless MFC is doing something on its behalf). It just has to sit there waiting for input for this problem to occur. It happens consistently the first time I type a chcracter in WINHELP's Search dialog. WINHELP has been started by the Program Manager, not by my program. Thanks in advance for any enlightenment on this. Keith There is 1 Reply. #: 15354 S6/API-Base/Security 19-Oct-92 08:20:38 Sb: #15328-Clobbering Memory Fm: Keith MacDonald 100041,235 To: Keith MacDonald 100041,235 (X) Upon closer inspection, the problem is caused by calling SetWindowsHookEx from my application (not a DLL) thus: hHook = SetWindowsHookEx(WH_KEYBOARD, (HOOKPROC)&kbdproc, hInstance, 0); The solution was to set the 3rd argument to NULL, and the 4th to GetCurrentThreadId(). This error occurred in the conversion from Windows 3.1, when I merged a DLL into the application to minimize the conversion effort, and that slipped through. It would be safer if SetWindowsHookEx did not return a usable HANDLE in this circumstance. There is 1 Reply. #: 15413 S6/API-Base/Security 19-Oct-92 20:12:27 Sb: #15354-Clobbering Memory Fm: Eric Sassaman/Microsoft 75430,411 To: Keith MacDonald 100041,235 (X) << Upon closer inspection, the problem is caused by calling SetWindowsHookEx from my application (not a DLL) thus: hHook = SetWindowsHookEx(WH_KEYBOARD, (HOOKPROC)&kbdproc, hInstance, 0); The solution was to set the 3rd argument to NULL, and the 4th to GetCurrentThreadId(). This error occurred in the conversion from Windows 3.1, when I merged a DLL into the application to minimize the conversion effort, and that slipped through. It would be safer if SetWindowsHookEx did not return a usable HANDLE in this circumstance. >> Keith, it would be great if you could let the folks in section 4 know about this problem. Personally I don't know if you were calling the SetWindowsHookEx correctly or not the first time; the folks in section 4 have much more expertise in this area than we do here, us being more nuts 'n bolts base-ish type of folks . It would be even more wonderful if you could forward some code snippets or a small sample app so that they could reproduce the problem - it looks like SetWindowsHookEx should return an error in this case so that it doesn't cause the interference with other applications that you've seen, and if this is the case, we should get this fixed. If the folks in section 4 can have a posting of yours there to reply to, they can keep you informed as to what happens with this problem. As well as the fact that others may run into this problem and may find your info very helpful. Thanks for your help. Eric Sassaman Microsoft NT Support #: 15378 S6/API-Base/Security 19-Oct-92 13:27:13 Sb: #15289-get_ftime() -> ?? Fm: Pete Grey [Microsoft] 70744,22 To: Jake Kirk 76207,1403 (X) >> I a little confused, per page 44 of the "Programming Techniques" guide it is implied that I should replace _dos_getftime() and _dos_setftime() with GetDateAndTimeFile() and SetDateAndTimeFile(). I think that I really should use GetFileTime(), but I can only use GetFileTime if I open my file with CreateFile(). But does CreateFile(), CloseHandle() and GetFileTime() do things in a manner that allow my application to share the same file in both the dos and NT environments? My app has to share the same file "database" format in both dos and NT, is there anything I should be aware of? Will my dos app still be able to use _dos_getftime() on files created under NT? << You should be able to use the CreateFile(), GetFileTime() combination to access the file times with NT, and still be able to use the same DOS functions to access it. There are even two calls, FileTimeToDosDateTime() and DosDateTimeToFileTime() that converts to the old style format, if you chose to share some date/time manipulation code. -pete There is 1 Reply. #: 15424 S6/API-Base/Security 19-Oct-92 23:29:01 Sb: #15378-get_ftime() -> ?? Fm: Jake Kirk 76207,1403 To: Pete Grey [Microsoft] 70744,22 (X) Thanks Pete. Will the documentation be corrected for the October release? //Jake. There is 1 Reply. #: 15459 S6/API-Base/Security 20-Oct-92 12:05:40 Sb: #15424-get_ftime() -> ?? Fm: Pete Grey [Microsoft] 70744,22 To: Jake Kirk 76207,1403 >> Will the documentation be corrected for the October release? << The online documentation has been greatly revised and corrected for this release, with many new overviews. There won't be a new hard-copy release of the docs. at this time. I think you'll be pleased with the new docs. and the contained overviews. -pete #: 15472 S6/API-Base/Security 20-Oct-92 13:26:17 Sb: #15198-NT File System Questions Fm: Eric Sassaman/Microsoft 75430,411 To: Anthony L. Iams 71175,2463 << 2) Are block fragments supported? >> The information that I've just recently received is that block fragments are not supported by NTFS. Concerning file journalling, this cannot be disabled. <<> There are no APIs that will allocate and guarantee a contiguous file. Here is a quote from the WINNT Forum a few weeks ago: > 29-Sep-92 13:46:00 > Sb: #9582-De-Frag for NT > Fm: Terence Hosken [MS] 71075,643 > ...HPFS and NTFS both have features that, if implemented > and used correctly, can minimize file fragmentation, > however. Under both file systems, for example, it is possible to > "pre-allocate" file space. If an application knows how much > disk space it will evenutally need, passes this information to the > file system, and the file system uses the information to allocate > a contiguous region, then subsequent output to the file will not > fragment the file... So does NTFS have preallocated files? How do you create one? >> Terence is correct. NTFS supports preallocated space. However, no Win32 API exists that takes advantage of this feature. The common technique to approximate this under Win32 is to create a file, SetEndOfFile to the size you wish, then write a 0 to the last position. NTFS will attempt to make your file as contiguous as possible, as HPFS does. Hope this cleared up any confusion on this issue. Eric Sassaman Microsoft NT Support #: 15377 S6/API-Base/Security 19-Oct-92 12:58:08 Sb: DLL Fm: Christian Betrisey 76600,1450 To: sysop (X) 19-OCT-92 - DLL / shared global variables I would like to share the global variables of a DLL 'mydll.dll'. I wrote the following into my 'mydll.def' file: DATA READ WRITE SHARED If two processes attach to 'mydll' ,then I still have 2 different sets of global variables! Did I forget to do something? Could you please give me a hint? Thank you for your help Christian Betrisey There is 1 Reply. #: 15414 S6/API-Base/Security 19-Oct-92 20:12:38 Sb: #15377-DLL Fm: Eric Sassaman/Microsoft 75430,411 To: Christian Betrisey 76600,1450 (X) << I would like to share the global variables of a DLL 'mydll.dll'. >> Christian, below is an article from the knowledgebase (go mskb) on how to do this: To have both shared and nonshared data in a dynamic-link library (DLL), you need to use the new #pragma data_seg directive to set up a new named section. You then specify the sharing attributes for this new named data section in your .DEF file. The #pragma directive applies only to 80x86 systems; it is not supported on MIPS systems. Below is a sample of how to define a named data section in your DLL. The first line directs the compiler to include all the data declared in this section in the MYSECTION data segment. This means that the iSharedVar variable would be considered part of the MYSECTION data segment. By default, data will be nonshared. The third line, "#pragma data_seg()", directs the compiler to reset the data to its previous setting. In this case, it is the default data section. #pragma data_seg("MYSECTION") int iSharedVar; #pragma data_seg() Below is a sample of the .DEF file that supports the shared and nonshared segments. This definition will set the default data section, DATA, to be nonshared and the section MYSECTION to be shared. LIBRARY DATA READ WRITE SECTIONS MYSECTION READ WRITE SHARED EXPORTS ... Hope this helps. Let me know if you run into any problems getting this to work. Eric Sassaman Microsoft NT Support #: 15513 S6/API-Base/Security 21-Oct-92 09:15:26 Sb: #15377-DLL Fm: John Stoddard 72400,2551 To: Christian Betrisey 76600,1450 (X) Christian, Also remember that when you use the variable from the .EXE that attaches to your .DLL, you will be referencing a POINTER TO the variable, not the variable. That is, if you have "int i" in your data_seg, you'll have "extern int *i" in your .EXE. This had me stumped for a while - see "global data in .DLLs" elsewhere in this section, Eric gave a very good explanation of the situation. John #: 15546 S6/API-Base/Security 21-Oct-92 14:14:15 Sb: DLL Fm: Christian Betrisey 76600,1450 To: 72400,2551 (X) Hi John Thank you for your hints. If you are using shared global data in a DLL, then look at my message #15545. I have another problem with that. Christian. #: 15562 S6/API-Base/Security 21-Oct-92 15:57:23 Sb: RegQueryKeyValue Fm: Marc Singer 72130,2546 To: Sysop (X) It appears that the RegQueryKeyValue () API has different types in the Windows 3.1 API than it does for the Win32 API. Neither compiler does not like converting unsigned long to long (nor vice versa). Should these not be the same for both APIs? Marc Singer -- Straylight Software #: 15585 S6/API-Base/Security 22-Oct-92 01:20:46 Sb: Event Time Stamps Fm: dan white 70324,3147 To: sysop (X) Is there any way to control the time stamp of an event written with ReportEvent? If there isn't, is there a way to find out what time stamp was used, and is there a maximum latency between the time ReportEvent is called and the time stamp? This is important because we track and time stamp events internally, but would like to write them to the event log. The only way to be sure the logged time matches our internal time is to either set the log time to match the internal time, or vise versa. Right now I see no way to do either. Thanks, Dan #: 15404 S6/API-Base/Security 19-Oct-92 18:03:46 Sb: #15173-Communications timeouts Fm: Pete Grey [Microsoft] 70744,22 To: Bruce Cowan 73650,32 >> The rationale is that this would let a communications application read all the data that is available immediately with no delays *and* wait for data for a timeout period, all with a single instance of FileRead and the app does not require the complexity of doing a WaitCommEvent or something else to avoid overhead when no data is available. With a WaitCommEvent the app would have to do its own total timeout timing, which seems contrary to the spirit of providing all these fancy timing facilities. << How about using an interval timeout with a fairly short interval. This would wait for the first character, and if you didn't get one real-soon (short timeout) would complete. I think this is what you are trying to achieve here. -pete #: 15579 S6/API-Base/Security 21-Oct-92 21:41:49 Sb: #15404-Communications timeouts Fm: Bruce Cowan 73650,32 To: Pete Grey [Microsoft] 70744,22 (X) That doesn't work (at least in the current release) because the shortest timeout you can specify is 1ms. and the internal interpretation of that seems to be that it will wait until the next timer tick, which, on an Intel 486 machine seems to be about 10ms. I know this because I have tried it and this is the behavior it exhibits. I really would like you to seriously consider the extension. It should be easy to implement and it does provide significant additional functionality. I suppose you could fix the interval timeout to actually work at 1 ms which would work for me, but I can't see an efficient way to do that. Bruce #: 15590 S6/API-Base/Security 22-Oct-92 04:18:51 Sb: #15404-Communications timeouts Fm: Bruce Cowan 73650,32 To: Pete Grey [Microsoft] 70744,22 (X) Further, if I use the short interval, then I can't read all the data that has already arrived with a single call, since any read that specifies a count greater than the available data will wait until a new character arrives and then the timeout interval. It could possibly be a *LONG* time until the next character arrives. I suppose I could use a call to find out how much data has arrived and then read exactly that much, but that is getting complex and it will suffer from the problem that because there are two separate calls, some data could possibly arrive between the calls and it won't be read. BTW, lots of communications port stuff is broken in the July release, but I am not bothering to report it because I am expecting the next release any moment now and thought I'd test things there before reporting problems. Bruce #: 15448 S6/API-Base/Security 20-Oct-92 09:31:15 Sb: #14948-Win32 Critical Sections Fm: David Edge 75170,1461 To: John Ballinger 73747,2703 I had the same problem. I posted a question about this a long time ago and the reply that I received was that there is a bug in the critical section code. The filer sample that is referred to in the response to your message exhibits the problem. If you put some extra space after the critical section structure and call the function to initialize it, you will notice that the critical section structure is unmodified but the extra space is. It seems that the address is getting messed up some how. Apparently if you just define that extra space for now you can work around the problem. There is 1 Reply. #: 15458 S6/API-Base/Security 20-Oct-92 11:01:31 Sb: #15448-Win32 Critical Sections Fm: neil colvin 71650,3517 To: David Edge 75170,1461 If you read the July release notes, page 33, you will find the solution to maing critical sections work properly. The really work perfectly!!! (the solution is to define DEVL during compilation.) #: 15609 S6/API-Base/Security 22-Oct-92 12:28:49 Sb: #15458-Win32 Critical Sections Fm: Bob Landau [Microsoft] 70744,21 To: neil colvin 71650,3517 (X) Thanks Neil, This is fixed in the Oct release. bob #: 15608 S6/API-Base/Security 22-Oct-92 12:28:45 Sb: #15448-Win32 Critical Sections Fm: Bob Landau [Microsoft] 70744,21 To: David Edge 75170,1461 (X) As Neil stated you need to define -DEVL; sorry it was buried so deep in the doc's. The good news is we've fixed the problem in the Oct release so others won't get bitten by this now. Microsoft Developer Support Bob Landau #: 15572 S6/API-Base/Security 21-Oct-92 19:12:36 Sb: ReadFile as a port Fm: Koby 71172,2722 To: sysop (X) Hi I am working on serial port read and write. The serial was opened as a file with an overlepped flag (as in the example tty.c). While I am reading the file I am getting a read error (return error == 0) and the GetLastError() reports error #998 ERROR_NOACCESS Invalid access to a memory location. All the parameter that are passed to the function are OK, I can watch their's values while debugging and the file creating, events, port setting where correct with no errors. Can You give me a clue how to solve this problem. Koby There is 1 Reply. #: 15613 S6/API-Base/Security 22-Oct-92 12:31:50 Sb: #15572-ReadFile as a port Fm: David Taniguchi [MS] 72350,2054 To: Koby 71172,2722 (X) Hi Koby, It's difficult to pin down what might be wrong without more specifics. However, one thing you might check is the the second, third and fourth parameters. Make sure that the length of the receiving buffer (parm 2) is the length specified by parm 3. Also notice in TTY they are using the minimum value of to value what ClearCommError() returns back in the ComStat structure. If you aren't already doing so, you might try directly using the ReadCommBlock() function in your program, until you figure out what is causing the error. Hope this helps, Dave #: 15635 S6/API-Base/Security 22-Oct-92 14:58:32 Sb: ExitWindowsEx? Fm: Ralph Smith 76376,3150 To: All Has anyone had any success with ExitWindowsEx? Using EWX_LOGOFF works fine, but EWX_REBOOT and EWX_SHUTDOWN don't do anything. If progman can do it, why not me ?? I just want to make a quick-shutdown icon program. TIA. - Ralph #: 15545 S6/API-Base/Security 21-Oct-92 14:08:58 Sb: DLL: shared data Fm: Christian Betrisey 76600,1450 To: sysop (X) 21-OCT-92 I am stuck with the following problem: I would like to share some global data of a DLL. I have done what you told me in message #15377-DLL. in mydll.c #pragma data_seg("MYSHAREDDATA") int iVal1 = 1; // initialized variable int iVal2; // non-initialized variable #pragma data_seg() ... iVal2 = 2; in mydll.def SECTIONS MYSHAREDDATA READ WRITE SHARED Now only the variable iVal1 is shared among my two applications. iVal2 is not shared. Program A (which initialized iVal2) reads iVal2=2 and program B reads iVal2=0! Note that the variables are only accessed by procedures. It seems to me that a non-initialized variable is not shared. I cannot explain myself why ? Thank you for your help. Christian There are 2 Replies. #: 15563 S6/API-Base/Security 21-Oct-92 16:15:00 Sb: #15545-DLL: shared data Fm: John Stoddard 72400,2551 To: Christian Betrisey 76600,1450 (X) Christian, The Microsoft folks did tell me elsewhere that you need to initialize the data... however my experiments show this isn't the case. I think the part you may be missing is an EXPORTS entry for the variable in your .DEF file, with the keyword CONSTANT, i.e. "i CONSTANT". That works for me. John There is 1 Reply. #: 15646 S6/API-Base/Security 22-Oct-92 17:21:39 Sb: #15563-DLL: shared data Fm: Eric Sassaman/Microsoft 75430,411 To: John Stoddard 72400,2551 << The Microsoft folks did tell me elsewhere that you need to initialize the data... however my experiments show this isn't the case. I think the part you may be missing is an EXPORTS entry for the variable in your .DEF file, with the keyword CONSTANT, i.e. "i CONSTANT". That works for me. >> Hm, my experience was the opposite - if you don't init the variable, it won't be shared. You won't need an export statement for the data in your def file unless you wanted to access the shared data by name from your exe, and the CONSTANT is only needed if you need to change the value of the data in the DLL directly from the .exe. Eric Sassaman Microsoft NT Support #: 15619 S6/API-Base/Security 22-Oct-92 13:53:47 Sb: #15545-DLL: shared data Fm: Eric Sassaman/Microsoft 75430,411 To: Christian Betrisey 76600,1450 (X) << I am stuck with the following problem: I would like to share some global data of a DLL. I have done what you told me in message #15377-DLL. in mydll.c #pragma data_seg("MYSHAREDDATA") int iVal1 = 1; // initialized variable int iVal2; // non-initialized variable #pragma data_seg() ... iVal2 = 2; in mydll.def SECTIONS MYSHAREDDATA READ WRITE SHARED Now only the variable iVal1 is shared among my two applications. iVal2 is not shared. Program A (which initialized iVal2) reads iVal2=2 and program B reads iVal2=0! Note that the variables are only accessed by procedures. It seems to me that a non-initialized variable is not shared. I cannot explain myself why? >> Christian, you are correct, non-initialized data will not be shared correctly. You must be sure to initialize all data that you want to share. I'm not sure why this is, but I'll look into it and let you know. Eric Sassaman Microsoft NT Support #: 15419 S6/API-Base/Security 19-Oct-92 22:46:41 Sb: #15267-global data in .DLLs Fm: Eric Sassaman/Microsoft 75430,411 To: John Stoddard 72400,2551 (X) << I will mail you a set of examples - they're too long to upload in the limited space available for a forum message. >> John, for future reference please note that it is very difficult for us to read our personal mail here on CIS. The software that we use to interface to CIS does not download our mail (at least right now). Please follow the instructions in the release notes on how and where to upload things like this. I'll see if I can get your mail downloaded - if I can't, I'll get back to you. Thanks! Eric Sassaman Microsoft NT Support #: 15420 S6/API-Base/Security 19-Oct-92 22:46:46 Sb: #15267-global data in .DLLs Fm: Eric Sassaman/Microsoft 75430,411 To: John Stoddard 72400,2551 (X) John, I found it. It was the #pragma data_seg("") line. It should be: #pragma data_seg(). It looks like a null string as a data segment name is different than no string at all... which makes sense. I'll send this off to the language folks to deal with - the least the compiler could do is give you a warning so you know where to poke around ! Thanks for reporting this problem - let me know where you get stuck next ! BTW this is _not_ fixed in the version of the compiler going out with the October release... Eric Sassaman Microsoft NT Support There is 1 Reply. #: 15449 S6/API-Base/Security 20-Oct-92 09:37:54 Sb: #15420-global data in .DLLs Fm: John Stoddard 72400,2551 To: Eric Sassaman/Microsoft 75430,411 (X) Great! Thanks, I'll try that. I have some suspicions that the structure alignment problems I have may disappear once I get the compile step to complete; if I remember correctly structure packing gets done on the last pass. I'll let you know how it works. John #: 15512 S6/API-Base/Security 21-Oct-92 09:08:14 Sb: #15420-global data in .DLLs Fm: John Stoddard 72400,2551 To: Eric Sassaman/Microsoft 75430,411 (X) Eric, This did indeed fix my compile problems. I had the #pragma line correct in two places in my code, but incorrect (with the NULL string) in another. It was apparently left over from an incorrect example I tried to follow from elsewhere in this forum. However, the structure alignment problem did not go away. Maybe in the next release of the tools... John There is 1 Reply. #: 15647 S6/API-Base/Security 22-Oct-92 17:21:49 Sb: #15512-global data in .DLLs Fm: Eric Sassaman/Microsoft 75430,411 To: John Stoddard 72400,2551 << This did indeed fix my compile problems. I had the #pragma line correct in two places in my code, but incorrect (with the NULL string) in another. It was apparently left over from an incorrect example I tried to follow from elsewhere in this forum. However, the structure alignment problem did not go away. Maybe in the next release of the tools... >> Your "foobar" tests that you sent worked fine on both the 297 and the build you will be receiving shortly, structure alignment and all (after the null string fix). I used -Zp4 and it worked fine. Did you use a different structure than the one you sent in the tests? I'm not sure what the problem could be, it worked ok here... Eric Sassaman Microsoft NT Support #: 15322 S6/API-Base/Security 17-Oct-92 18:34:41 Sb: new "windowsx.h" for 3.1 Fm: Jake Kirk 76207,1403 To: sysop (X) I can't seem to find the update to the win3.1 sdk. I though I saw it here. Can you please tell me what forum the update is in? I need the update as it contains macros that are used in NT to solve the parameter packing issues w/NT. I know I saw it someware on compuserve. Thank you. //Jake. There is 1 Reply. #: 15403 S6/API-Base/Security 19-Oct-92 18:03:40 Sb: #15322-new "windowsx.h" for 3.1 Fm: Pete Grey [Microsoft] 70744,22 To: Jake Kirk 76207,1403 (X) >> I can't seem to find the update to the win3.1 sdk. I though I saw it here. Can you please tell me what forum the update is in? I need the update as it contains macros that are used in NT to solve the parameter packing issues w/NT. I know I saw it someware on compuserve. << Not sure where to tell you to look for this. I would ask someone in the Windows 3.1 SDK forum for starters. -pete There is 1 Reply. #: 15423 S6/API-Base/Security 19-Oct-92 23:27:22 Sb: #15403-new "windowsx.h" for 3.1 Fm: Jake Kirk 76207,1403 To: Pete Grey [Microsoft] 70744,22 (X) Guess what, they asked me to look here and over in the WINNT forum. Gee, I know I saw that file some where.....? //Jake. There is 1 Reply. #: 15428 S6/API-Base/Security 20-Oct-92 01:02:53 Sb: #15423-new "windowsx.h" for 3.1 Fm: Brad Hines 76520,3314 To: Jake Kirk 76207,1403 The file you are looking for is called WIN16X.ZIP and is in lib 7, Tools. #: 15672 S6/API-Base/Security 23-Oct-92 06:09:56 Sb: #15428-new "windowsx.h" for 3.1 Fm: Jake Kirk 76207,1403 To: Brad Hines 76520,3314 Thank you very much for the location and the name of WIN16x.zip //Jake. #: 15673 S6/API-Base/Security 23-Oct-92 06:28:20 Sb: -1 = DialogBox(....); Fm: Jake Kirk 76207,1403 To: ALL I have just ported 95% of an app to NT. But out of 25 or so dialog boxes I have 1 dialog box that refuses to come up! I don't know why this dialog box should fail, but it does. DialogBox() returns -1 when trying to create it. Any suggestions or explainations? (The instance handle was OK, the dialog rc file looked ok, this is a puzzle!) //Jake. There are 2 Replies. #: 15684 S6/API-Base/Security 23-Oct-92 09:33:05 Sb: #15673- -1 = DialogBox(....); Fm: David Edge 75170,1461 To: Jake Kirk 76207,1403 My experience with dialog box problems is that there is something wrong with one of the controls. Can you load the dialog template into the dialog editor? If the dialog editor can load it and resave it then perhaps this would help. Also, custom controls can cause problems. Does the dialog proc ever get called? #: 15689 S6/API-Base/Security 23-Oct-92 11:06:08 Sb: #15673- -1 = DialogBox(....); Fm: Bob Landau [Microsoft] 70744,21 To: Jake Kirk 76207,1403 Jack, This is the wrong section to be posting user info. We try to keep all related threads in one spot i.e. User API's in the 4 section ( API-User Interface ). This way users of this forum can minimize their CIS cost by downloading only the sections their interested in *and* be guarentted that the have not missed out in some important detail. Post this in the User section and I or someone else will answer this. And since your re-posting this please give us the following info 1) Please double check the parameters to DialogBox(). 2) What does GetLastError(). In general when any Win32 API fails this call will give both you and us more details as to why. 3) Will pasting the code and resource into say Generic generate the same failure? 4) Is the dialog template create with in the resource file as the rest? a different file? or on the fly? 5) Anything unusual about the Dialog template? i.e. user defined controls? or private dialog? Thanks Microsoft Developer Support Bob Landau #: 15539 S6/API-Base/Security 21-Oct-92 13:53:16 Sb: Redirected I/O & Pipes Fm: Keith MacDonald 100041,235 To: SYSOP (X) I'm trying to programmatically achieve the same end as a batch file command such as: grep "pattern" file1 file2 2>&1 | more ie. to redirect both the standard output and standard error of a child process to the same pipe. Here, courtesy of the online help example (and stripped of declarations and error handling), is how I'm trying to do it: // Create an anonymous pipe: sec.nLength = sizeof(SECURITY_ATTRIBUTES); sec.bInheritHandle = INHERIT; sec.lpSecurityDescriptor = NULL; CreatePipe(&hChildStdoutRd, &hChildStdoutWr, &sec, 0); // Redirect child's stdout to the pipe: DuplicateHandle(GetCurrentProcess(), GetStdHandle(STD_OUTPUT_HANDLE), GetCurrentProcess(), &hSaveStdout, 0, FALSE, DUPLICATE_SAME_ACCESS); SetStdHandle(STD_OUTPUT_HANDLE, hChildStdoutWr); // Redirect child's stderr to the pipe: DuplicateHandle(GetCurrentProcess(), GetStdHandle(STD_ERROR_HANDLE), GetCurrentProcess(), &hSaveStderr, 0, FALSE, DUPLICATE_SAME_ACCESS); SetStdHandle(STD_ERROR_HANDLE, hChildStdoutWr); // Create the child process: sInfo.cb = sizeof(STARTUPINFO); sInfo.lpReserved = sInfo.lpReserved2 = NULL; sInfo.cbReserved2 = sInfo.lpDesktop = NULL; sInfo.lpTitle = NULL; sInfo.dwFlags = 0; CreateProcess(NULL, lpszCommand, NULL, NULL, TRUE, 0, NULL, NULL, &sInfo, &procinfo); // Restore saved stdout & stderr: SetStdHandle(STD_OUTPUT_HANDLE, hSaveStdout); SetStdHandle(STD_ERROR_HANDLE, hSaveStderr); // Close our write end of pipe: CloseHandle(hChildStdoutWr); // Read the child's output from the pipe: readFromPipe(hChildStdoutRd); This works for a single child process, but if the child creates its own sub-processes (such as cl386.exe does), the second generation's output disappears into the ether. Since cmd.exe can achieve it, it's obviously possible. Please can anyone help me with this? Keith There is 1 Reply. #: 15690 S6/API-Base/Security 23-Oct-92 11:06:14 Sb: #15539-Redirected I/O & Pipes Fm: Bob Landau [Microsoft] 70744,21 To: Keith MacDonald 100041,235 Hi Keith, The problem I see right off is sixth parameter is set to FALSE which means processes created by child process will not inherit the handle; set this to TRUE and you will get the behavior you desire DuplicateHandle(GetCurrentProcess(), GetStdHandle(STD_ERROR_HANDLE), GetCurrentProcess(), &hSaveStderr, 0, FALSE, ^^^^^ DUPLICATE_SAME_ACCESS); Microsoft Developer Support Bob Landau #: 15454 S6/API-Base/Security 20-Oct-92 10:01:30 Sb: C++ Exports in DLLs Fm: Keith MacDonald 100041,235 To: SYSOP (X) I'm trying to create a DLL from my C++ source that works fine in Windows 3.1. My problem is that I need to specify the exported names in my .DEF file, in their decorated form, so that COFF can generate a .EXP file. I've tried two approaches to getting the decorated names: 1) Link my application and use the names from the undefined externals error messages. 2) Extract the names from the .OBJ file for the DLL. In either case, I get "name is undefined" messages whenever I get COFF to link my DLL. Can somebody PLEASE help me? #: 15606 S6/API-Base/Security 22-Oct-92 12:28:34 Sb: #15454-C++ Exports in DLLs Fm: Bob Landau [Microsoft] 70744,21 To: Keith MacDonald 100041,235 (X) Keith, Sorry for not getting to this sooner. I will look into this today. I believe that simply listing the OBJ.s on the LIB line will do this. Try this is the makefile. lib -machine:$(cpu) \ -def:.def \ -out:.lib \ Please let me know whether you are exporting classes or functions I believe the former is more difficult. Again I'll look into this today and post another response by tomorrow. Microsoft Developer Support Bob Landau There are 3 Replies. #: 15629 S6/API-Base/Security 22-Oct-92 14:31:01 Sb: #15606-C++ Exports in DLLs Fm: Keith MacDonald 100041,235 To: Bob Landau [Microsoft] 70744,21 (X) Bob, Thanks for the suggestion. If I add the names to the EXPORTS section in the .DEF file and the object files as you suggest, it works. All I need now is for the MAP output file option to work to simplify getting the decorated names. Thanks again. Keith #: 15676 S6/API-Base/Security 23-Oct-92 07:03:58 Sb: #15606-C++ Exports in DLLs Fm: Keith MacDonald 100041,235 To: Bob Landau [Microsoft] 70744,21 (X) Bob, Further to my apparent success yesterday. By including the .OBJ file in the LIB command, I actually got a static library, which linked successfully with my program, but did not give me the DLL that I wanted. The real problem is that LIB takes the names in the EXPORTS section of my .DEF file (which I have manually extracted from the .OBJ file) and writes a .EXP file with the names prepended with an underscore. This is OK for C, but not for C++. I've tried declaring the subroutines as __cdecl in my source, but they still get translated to the C++ decorated form. I'm in a Catch 22 situation here, because COFF won't allow me to use my application's .DEF file to use the alternate technique of specifying the names in an IMPORTS section. Since discovering this, your colleague Doug Olson has sent a message confirming that this is a known problem. Any further help would be very gratefully accepted! Keith #: 15691 S6/API-Base/Security 23-Oct-92 11:06:20 Sb: #15606-C++ Exports in DLLs Fm: Bob Landau [Microsoft] 70744,21 To: Bob Landau [Microsoft] 70744,21 (X) Keith, I neglected to mention you needed "decorate" the dll EntryPoint also. There is a manifest constant in the Oct release "DLLENTRY" which on a i386 platform will appended a @12 which is signature that the compiler puts on the entry point. Please let me know if you are still having any difficulties, and again are you exporting function or a class. Microsoft Developer Support Bob Landau #: 15544 S6/API-Base/Security 21-Oct-92 14:06:04 Sb: Messages to other app. Fm: Christian Betrisey 76600,1450 To: sysop (X) 21-OCT-92 Hi! Is it possible in NT to post a message from one application to another? I am trying to port one of our programs from Windows 3.1 to NT. This program is a DLL wich allows an application (*.exe) to send Windows' messages to another application. The receiver then retrieves the data stored in the DLL by the sender. I plan to use the NT mailslots or pipes but I also would like to be able to port our DLL as a try (our benchmarks show that our 3.1 DLL is faster than the NT mailslots/pipes). It seems to me that this is not possible because in Windows 3.1 we are using 'GetCurrentTask' to store the handles of all our applications in the DLL. In Windows NT, 'GetCurrentProcess' returns 0xFF..FF for all applications! Thank you for your help Christian There is 1 Reply. #: 15692 S6/API-Base/Security 23-Oct-92 11:06:27 Sb: #15544-Messages to other app. Fm: Bob Landau [Microsoft] 70744,21 To: Christian Betrisey 76600,1450 (X) Christian, I'd hoped to get to this today unfortunately will not be able to get to this. My understanding is you can do the following to get a "real" handle. Note that GetCurrentProcess() only returns a psuedo handle which *only* has meaning in the context of the calling process. hpsuedoHandle = GetCurrentProcess(); retCode = DuplcateHandle( hpsuedoHandle, hpsuedoHandle, // Must be a "real" handle with at least PROCESS_DUP_HANDLE priviledge. &hRealHandle, , // Ignored if DUPLICATE_SAME_ACCESS is specified below , // TRUE means a child process of the target process can inherit the handle. DUPLICATE_SAME_ACCESS ) I am going to generate a quick sample but I can't get to this today. I there're any more issues which I've not mentioned above I will post a follow up on Monday. Microsoft Developer Support Bob Landau #: 15362 S6/API-Base/Security 19-Oct-92 09:59:55 Sb: #15298-Multi-user / X Support? Fm: Paul Sutter 70451,1500 To: Bruce Ramsey/Microsoft 70324,2742 (X) Bruce, Thanks for your response; it certainly clarified what NT will and will not allow. When I was referring to an Xclient for NT, I did not mean just port the XLIB over, I meant to create a driver so that GDI calls would be emulated as X messages,... so that any Windows application could run on a remote X terminal; the remote X terminal would be a 'remote' display device for standard Windows programs. This would have tremendous value, particularly in IS shops. If NT is going to stomp on Unix, this should be addressed. But since the first release of NT wont have multiuser capability, let it stand as a suggestion. Paul Sutter Voila! Software #: 15703 S6/API-Base/Security 23-Oct-92 11:52:30 Sb: Multi-user / X Support? Fm: Bruce Ramsey/Microsoft 70324,2742 To: John Richardson 70541,672 Hi Paul, and John - All of the third parties we've talked to who are working on Xlib (although not a huge list) have asked us not to discuss their activities, as they wish to make their own announcements. You might, if you haven't already, try contacting some third parties yourself. They might be willing to discuss their plans one-on-one with you, or under NDA I don't think it's going to be possible to write a device driver for Windows NT that does what you suggest regarding redirecting GDI calls to a remote X terminal. At least not in the first commercial release of Windows NT. I may, however, have misunderstood what you meant Redirecting GDI calls isn't something a video driver will be able to do, because the Win32 subsystem will already have rendered GDI calls (as well as USER calls), into lower level calls that the video driver must implement as GRE (GRaphics Engine) calls Also, even if such a driver were possible, it would not address issues of getting keyboard/mouse input from the X terminal back to the X client app While I would agree that it would be of benefit for any X terminal to be able to run any arbitrary app for Windows that is installed on a machine running Windows NT, or that remoting the desktop to an X terminal would be of benefit, unless I've misunderstood this isn't going to be doable in the first commercial release Shouldn't people who port existing Xlib apps to Windows NT using a third party version of Xlib for Windows NT be able to provide benefits to users of that ported app similar to the benefits the users now enjoy with the app? I state this as a question because I still have a lot to learn about Xlib :) The first commercial release of Windows NT will have multi-user capability, but only in the ways I explained previously: multiple users accessing it as clients of a named-pipes or RPC client-server app. Multiple users accessing it by connecting to shared disk directories or shared printers. And, by installing applications as services under the Service Control Manager [More] There is 1 Reply. #: 15705 S6/API-Base/Security 23-Oct-92 11:52:39 Sb: #15703-Multi-user / X Support? Fm: Bruce Ramsey/Microsoft 70324,2742 To: Bruce Ramsey/Microsoft 70324,2742 (X) [Continued] (possibly on the fly using the CreateService api), applications can be made to run under more than one user id at the same time Also, the ability to remotely administer Windows NT will be in the first commercial release. How soon remote admin would be possible via an X terminal I have no idea, but certainly from day one this will be possible from any machine on the net running Windows NT. And there will be dial-up facilities allowing Windows NT machines to, over dial-up lines, become full participants on the net In terms of remoting the interface of an arbitrary app for Windows installed on a machine running Windows NT, for new apps there is the option of making the interface an RPC client, and anything behind the interface RPC server code. Then the RPC client code can be run from any machine running a software platform for which we support RPC clients. Currently this includes Windows 3.1, MS-DOS, and Windows NT. And the RPC client code could be ported to any machine that runs DCE RPC client programs Yes! :-) I realize the facilities I've mentioned in the above three paragraphs aren't what you're looking for. I don't mention them to try to over-sell you on what will be there in preference to what you're after. The reason I mention them is for the benefit of other forum readers who may read this without being previously aware of what Windows NT does provide in these areas Regarding the company you asked about, I believe their name is Citrix and their number is 1-800-437-7503 Bruce #: 15450 S6/API-Base/Security 20-Oct-92 09:39:35 Sb: DLL addresses Fm: David Edge 75170,1461 To: all I have a question about where DLLs reside in the address space. As I understand it, a DLL has a separate data space that resides in the address space of the process that is using the DLL. If this is true, then the data addresses would be different within the DLL. Does a DLL share the same code for different processes or is it loaded again? #: 15494 S6/API-Base/Security 20-Oct-92 19:25:01 Sb: #15450-DLL addresses Fm: John Hall [MS SDE] 70750,2341 To: David Edge 75170,1461 (X) The code is shared, except for a small fix up table which points to any other DLL's that the dll uses. #: 15607 S6/API-Base/Security 22-Oct-92 12:28:41 Sb: #15450-DLL addresses Fm: Bob Landau [Microsoft] 70744,21 To: David Edge 75170,1461 (X) David as John stated the code is shared amongst processes. The data in the DLL *will* be different (copy will be made) for each process that hooks to this DLL. This is normally what one wants; you are able to override this behavior if you need the static data in the DLL to be shared between *all* processes that hook to the DLL. To do this one would first wrap the data in the DLL as follows // global data. is the name of your data section. #pragma data_seg("","") .. data .. #pragma data_seg(".data","") // instance data ... Next in the DLL's def file add the following line SECTIONS READ WRITE SHARED Microsoft Developer Support Bob Landau There are 2 Replies. #: 15682 S6/API-Base/Security 23-Oct-92 09:19:50 Sb: #15607-DLL addresses Fm: David Edge 75170,1461 To: Bob Landau [Microsoft] 70744,21 (X) If the data is separate for each process, how does the DLL resolve its data addresses. Won't the data addresses be different for the different instances of the DLL since the data has to map into the address space of the caller's process? #: 15707 S6/API-Base/Security 23-Oct-92 11:58:22 Sb: #15607-DLL addresses Fm: neil colvin 71650,3517 To: Bob Landau [Microsoft] 70744,21 (X) All the discussion about sharing static data has been clear. However, how does one share dynamic data (GlobalAlloc). The GMEM_SHARE option doesn't work anymore, so what is the solution? #: 15627 S6/API-Base/Security 22-Oct-92 14:00:36 Sb: File Name Associations Fm: Andrew Potter 71075,614 To: All Currently, Microsoft uses the file name extension to predict which application should be invoked when the file is double-clicked. Will this continue to be the method, or will files have well-defined announcement information embedded into them? If the current scheme is to be perpetuated, name-space collisions could become an issue. Will Microsoft provide a clearinghouse for well-known file extensions, and can developers reserve a range of names for their applications? There is 1 Reply. #: 15683 S6/API-Base/Security 23-Oct-92 09:30:28 Sb: #15627-File Name Associations Fm: David Edge 75170,1461 To: Andrew Potter 71075,614 Here's my two cents on this issue. I know that you can't really add stuff to the data portion of a file to recognize it, however, now that we have new file systems, will there be an extended attribute for the application name? Since HPFS and NTFS do not really have file extensions, the extension scheme is really a poor method of detecting file types. There is 1 Reply. #: 15714 S6/API-Base/Security 23-Oct-92 13:22:21 Sb: #15683-File Name Associations Fm: Marc Singer 72130,2546 To: David Edge 75170,1461 Amen. But there is also the problem of portability. How will me send files from machine to machine (via floppy) and retain these special attributes. Can we expect a new floppy format? #: 15351 S7/Tools-Microsoft 19-Oct-92 06:52:46 Sb: #15285-ODBC Availability Fm: David Van Camp 70740,366 To: David Taniguchi [MS] 72350,2054 (X) Thanks, Dave. That's what I expected you to say! I'll be looking foward to an announcement about ODBC NT sometime in the future. until then.... dvc #: 15365 S7/Tools-Microsoft 19-Oct-92 10:43:22 Sb: #15259-RC PUSHBOX Statement Fm: David Taniguchi [MS] 72350,2054 To: Samuel Feldman 70403,432 (X) Hi Samuel, Sorry for the delay. You are correct. The BS_PUSHBOX was not defined in Win 3.1 and it was only left in 3.0 for compatibility reasons. Thanks for pointing this out. This should be changed after the Oct. release. Thanks, Dave #: 15366 S7/Tools-Microsoft 19-Oct-92 10:43:27 Sb: #15278-DLL Fm: David Taniguchi [MS] 72350,2054 To: Christian Betrisey 76600,1450 (X) Hi Christian, This question would be better suited for the base section (section 6 - API Base/Security). They are more experienced with these types of issues. Thanks, Dave #: 15341 S7/Tools-Microsoft 19-Oct-92 03:57:29 Sb: Pview/Pstat in base? Fm: David A. Solomon 71561,3603 To: sysop sysop (X) I asked this a month or so ago but never got a reply -- the question is: why are Pview, Pstat, and the CPU Thermometer only in the SDK vs. in the base NT operating system? Pview at least seems to merit going into the base OS since it is a general system mgmt tool, and especially because there is no way in the base OS to display all processes, kill a process, etc. But all 3 of these utilities would make sense in the base vs in the SDK. Could someone from MS get an answer on this one? Thanks! There is 1 Reply. #: 15372 S7/Tools-Microsoft 19-Oct-92 12:05:42 Sb: #15341-Pview/Pstat in base? Fm: David Taniguchi [MS] 72350,2054 To: David A. Solomon 71561,3603 (X) Hi David, (For some reason this must not have made it up on to CIS. This is from Sept 1! Sorry for the delay) Yes, we want to incorporate Pview into the system. The information in pstat and cputherm will be part of other tools. Thanks, Dave #: 15384 S7/Tools-Microsoft 19-Oct-92 14:07:39 Sb: #14943-C++ debug Fm: Denis Gilbert (MS) 75230,1570 To: Urban Karlsson 100022,620 (X) Hi, Urban. I can answer your question about a Microsoft IDE for NT. Yes, we'll have a graphical IDE for Windows NT. And, yes, there are many developers working on this project. I can't give you a specific date but it's a VERY high priority project for us. -Denis // Microsoft Team C++ Development There is 1 Reply. #: 15432 S7/Tools-Microsoft 20-Oct-92 02:35:28 Sb: #15384-C++ debug Fm: Urban Karlsson 100022,620 To: Denis Gilbert (MS) 75230,1570 Thanks for this refreshing info, Denis! I kind of suspected that this project is a high priority projcet and I'm real glad that it is. Looking forward to having this killer app installed in my machine. Thanks again, -Urban #: 15441 S7/Tools-Microsoft 20-Oct-92 06:56:10 Sb: Compiler bug - alloca Fm: Jeff Thomson 71460,3222 To: All While attempting to compile some C code that contains a call to _alloca(), I encountered the following error message: memtest.c Compiler error (assertion : INTRINSIC not yet): file @(#)cgintrin.c:1.54, line 468 source=8 INTRINSIC NYI: IV_ALLOCA It looked as though the compiler was attempting to make the _alloca() call intrinsic (even though I wasn't using -Oi), so I tried adding #: 15466 S7/Tools-Microsoft 20-Oct-92 12:51:12 Sb: #15441-Compiler bug - alloca Fm: Doug Olson [Microsoft] 72350,2635 To: Jeff Thomson 71460,3222 (X) Jeff: Thanks for reporting these problems. The _alloca function will be available in up coming release. You will still encounter the C2163 error if you use #pragma function(_alloca), however since the first problem will go away, you will not need to use this pragma. Sincerely, Doug Olson Microsoft Developer Support #: 15471 S7/Tools-Microsoft 20-Oct-92 13:22:45 Sb: Common dialog include Fm: Marc Singer 72130,2546 To: Sysop (X) The July SDK includes the common dialog code without restraint. If I set the NOTEXTMETRIC or NOGDI defines to exclude parts of the windows include structure, I receive an error when it compiler gets to looking at the common dialog header. The structures there require LOGFONT, but do not check for the presence of it. What I would prefer is to have a define to exclude the common dialog structures. Marc Singer -- Straylight Software #: 15473 S7/Tools-Microsoft 20-Oct-92 13:34:55 Sb: linker bug? Fm: Mark L Hornick 70413,1717 To: Microsoft Can anyone out there tell me if I am suffering from a basic misunderstanding or if I have found a bug in the linker? The situation is as follows: I'm porting a multi-process UNIX application to a single-process multi-thread NT application, and I've accidentally stumbled onto a phenomenon that I can't explain. I've got two files: TEST1.C and TEST2.C. Inside TEST1.C are the routines main(), subA(), sub1(), and sub2(), where main() calls subA() and subA() calls sub1() and sub2(). Inside TEST2.C are subB() and ALSO sub1() and sub2(), where subB() calls sub1() and sub2(). TEST2.C's sub1() and sub2() are substatially different in structure from TEST1.C's sub1() and sub2(). In TEST1.C's main(), CreateThread() is called with TEST2.C's subB() as the start address of the new thread. After the CreateThread() call, main() then calls subA(). The two files are compiled and linked into one executable. The strange thing about it is that the linker gives no warning or error messages regarding multiple definitions of sub1() and sub2(). Even stranger, however, is that the resulting program seems to run OK. So my questions are: Why doesn't the linker complain? and How and why does it work? I'm compiling with cl386 with flags -W4 -Di386=1 -Od -G3d. I'm linking with coff with flags /link -subsystem:console -entry:mainCRTStartup Thanks, Mark Hornick #: 15347 S7/Tools-Microsoft 19-Oct-92 04:41:35 Sb: MFC Compiling Fm: RAYMOND MILTON WOOD 76550,404 To: 74375,313 (X) Bill, I checked my environment variables with the SYSTEM icon under the NT Control Panel. I appear to be configured okay. I then looked at the makefile for the MFC Helloapp sample. It uses CL instead of CL386 for a compiler. Doesn't NT require CL386? Ray There are 2 Replies. #: 15352 S7/Tools-Microsoft 19-Oct-92 08:02:40 Sb: #15347-MFC Compiling Fm: Bill Cohagan 74375,313 To: RAYMOND MILTON WOOD 76550,404 (X) Raymond- I just ran nmake for the MFC Hello sample with no problems. I ran both with and without the debug=1 argument. So -- we'll just have to figure out what's different in you makefile (or environment.) One thought occurred to me that might be a quick fix. You aren't, by any chance, running the MFC examples from a non NT version of C++, SDK, or whatever are you? The ones I'm running came on the NT distribution CD and are different (at least the makefiles) than the pre NT versions. Since I don't actually have the pre NT versions I can't say whether there are other differences. One way to tell, I suppose, is to look at your makefile and see if you find the line: #include ..\ntsample.mak If so, then I don't know why you are getting cl rather than cl386 because, in the above include file is the line: CC=cl386 which redefines the default C compiler to be the NT version. If, in fact, you *do* have this line but still don't get cl386 then it must be that NTMFC is *not* defined in your environment, causing the path in the makefile to skip the include file altogether. One last longshot... Are you logged in the same way when you check the environment as you are when you actually run the nmake? I believe that environment settings are local to a particular login -- so you might have set them up under one login and are running under another. Just a thought. Good Luck, Bill #: 15370 S7/Tools-Microsoft 19-Oct-92 11:39:01 Sb: #15347-MFC Compiling Fm: Doug Olson [Microsoft] 72350,2635 To: RAYMOND MILTON WOOD 76550,404 (X) Raymond: Sorry to hear that you are having problems building the MFC samples. Below are my general notes on building these applications. I also suggest typing SET and enter at the command prompt to verify the settings of the environment variables. Please let me know if this problem continues. The MFC samples that are included with the Developers Release of Windows NT can be compiled with the provided NMAKE files. A batch file named BLDSAMPLE.BAT can be used to build all of the MFC samples. Before executing BLDSAMPLE.BAT or any of the individual NMAKE files set the following environment variables: SET LIB=C:\MSTOOLS\LIB SET INCLUDE=C:\MSTOOLS\MFC\INCLUDE;C:\MSTOOLS\H SET NTMFC=1 SET RETAIL=1 After setting these environment variables you can execute the BLDSAMPLES.BAT batch file or change to any of the sample directories and simply execute NMAKE with no parameters. More Information: When running the BLDSAMPLES.BAT batch file you need to execute it in one of the following ways: BLDSAMP retail BLDSAMP debug The first example performs a release build where the second performs a build with debug information. Please note that the LIB environment variable must be set to C:\MSTOOLS\LIB because NTSAMPLE.MAK uses it to build the paths to all the libraries. You CANNOT have more than one subdirectory listed on the LIB environment variable when using the provided NMAKE files. Sincerely, Doug Olson Microsoft Developer Support There is 1 Reply. #: 15436 S7/Tools-Microsoft 20-Oct-92 05:40:08 Sb: #15370-MFC Compiling Fm: RAYMOND MILTON WOOD 76550,404 To: Doug Olson [Microsoft] 72350,2635 (X) Doug, I just uploaded a file called MFCHELP.TXT into the New Uploads section which contains the results of running SET, the contents of the makefile for one of my MFC samples, and the error msgs I get when I try to nmake that makefile. I would be curious to get your input on this. Thanks, Ray There is 1 Reply. #: 15474 S7/Tools-Microsoft 20-Oct-92 13:36:45 Sb: #15436-MFC Compiling Fm: Doug Olson [Microsoft] 72350,2635 To: RAYMOND MILTON WOOD 76550,404 Raymond: I will retrieve the file and take a look at it. I will let you know what I find. Thanks, Doug Olson Microsoft Developer Support #: 15323 S7/Tools-Microsoft 18-Oct-92 02:04:29 Sb: #15161-Compiler err (assertion) Fm: Brad Hines 76520,3314 To: Doug Olson [Microsoft] 72350,2635 (X) Thanks for your reply. I decided to make a concerted effort to determine what circumstances cause this bug. After several hours of whittling down my code, I have a small sample program that demonstrates the bug. Meanwhile, I also came up with a workaround for the bug so that I can keep going. Of course, then I uncovered some problem with the librarian, but that'll be the subject of another message. There is also another problem that I am having with the compiler disallowing certain forward declaration/typedef combinations that should be allowed. Basically, I think the following should be allowed, but it is flagged as an error by the compiler (programs using this syntax compile and run fine under Zortech and Borland C++): class myClass; typedef void (myclass::*PMYCLASSPROC)(int); At any rate, I have example code and descriptions for both these problems, but it's a little large to put in a mail message. I'm pretty new to Compuserve, so I don't know what the standard procedure is here. I assume that I can just upload a zip file to you, but I'm not quite sure where to put it or even what the options are. So just let me know what you'd like me to do. Thanks, Brad #: 15429 S7/Tools-Microsoft 20-Oct-92 01:02:57 Sb: #15161-Compiler err (assertion) Fm: Brad Hines 76520,3314 To: Doug Olson [Microsoft] 72350,2635 (X) Doug, I found the section in the NT release notes on uploading a file to Compuserve. I have made a file called CMPBG1.ZIP that I am uploading to lib 7, Tools, that contains sample programs for the two CL386 compiler bugs that I have mentioned in my posts. Let me know if you have any problem reproducing these errors. Thanks, Brad There is 1 Reply. #: 15475 S7/Tools-Microsoft 20-Oct-92 13:36:50 Sb: #15429-Compiler err (assertion) Fm: Doug Olson [Microsoft] 72350,2635 To: Brad Hines 76520,3314 Brad: Thanks for uploading the samples. I will work with these to determine the cause of the problem and then get back with you. Thanks again for your help, Doug Olson Microsoft Developer Support #: 15496 S7/Tools-Microsoft 20-Oct-92 19:40:58 Sb: #15085- Possible Compiler Bug Fm: Doug Olson [Microsoft] 72350,2635 To: Andrew Potter 71075,614 (X) Andrew: Thanks for waiting on this problem. The reason the time value is being rounded up has to do with the way the FAT file system stores time values. When a time is stored along with a date in a FAT directory entry, it is in 2-second increments. In this case, when the NT FAT file system writes the time and date to the file, the odd number of seconds is being rounded up. Here is another item that you may have discovered. Under NT it is necessary to fill in both the .actime and .modtime members of the utimbuf structure before calling _utime. The validation of the .actime member by _utime is due to the possibility that the installed file system may keep track of the last access to the file. I hope this clears up the confusion regarding the file time stamp. Sincerely, Doug Olson Microsoft Developer Support #: 15519 S7/Tools-Microsoft 21-Oct-92 10:13:51 Sb: Errors with C/C++ (C7) Fm: Ken Joyner 75140,256 To: Sysop (X) Is there a way of getting more info on a compiler error through the compiler itself? Were do I find the "Comprehensive Index and Errors Reference" referenced on Page 67 of the "Tools" Where can I get a bug report on the C/C++ compiler? I'm having problems with some code the works under AT&T, Borland, and MetaWare? Bryan #: 15485 S7/Tools-Microsoft 20-Oct-92 14:43:53 Sb: CDPlayer Fm: Howard Myers 76711,462 To: Microsoft I just received the October release. Unfortunately, I can no longer get the CD Player to work. It detects the drive (and in fact will eject the disk), but constantly gets read errors when trying to read it. The install program obviously read from it okay. The install brochure that came with the disk says that CDAUDIO.SYS must be installed, but isn't by default. Unfortunately, it doesn't tell you how to install it (I'm assuming this is my problem). How do I get CDAUDIO.SYS to load on statup? #: 15524 S7/Tools-Microsoft 21-Oct-92 12:25:19 Sb: #15485-CDPlayer Fm: David Taniguchi [MS] 72350,2054 To: Howard Myers 76711,462 (X) Hi Howard, This section is for developer tools. For setup problems, please post in Forum WinNT, section 3 (Windows NT Setup). They are more experienced with setup issues. Thanks, Dave #: 15350 S7/Tools-Microsoft 19-Oct-92 06:40:08 Sb: Dialog Editor Fm: Paul Ligeski 76636,1166 To: Sysop (X) Hi, Why does the Dialog Editor not recognize RES files? I recompiled my RC file under NT and tried to modify a dialog in the subsequent RES file with the Dialog Editor. I got "The Dialog Editor does not recognize this resource format." --Paul There is 1 Reply. #: 15368 S7/Tools-Microsoft 19-Oct-92 11:22:40 Sb: #15350-Dialog Editor Fm: Paul Tissue [Microsoft] 70744,24 To: Paul Ligeski 76636,1166 Hello Paul, There are two RES files generated by the resource compiling process. The first pass (running RC.EXE) compiles to a RES file that is not properly aligned for linking into a Win32 application. This first RES file is the one recognizable by the Dialog Editor. The second pass (running CVTRES.EXE) properly aligns the RES file for inclusion (linking) into a Win32 application. We recommend that you use the extension RES for the first pass and RBJ (Resource Object) for the second pass. Our new SDK codes samples, found in the October release of the Win32 SDK, reflect this new naming convention. - Paul, Win32 SDK Developer Support #: 15510 S7/Tools-Microsoft 21-Oct-92 09:05:38 Sb: #15368-Dialog Editor Fm: Paul Ligeski 76636,1166 To: Paul Tissue [Microsoft] 70744,24 (X) Hi Paul, Thank you for clearing up this issue of the Dialog Editor. I appreciate knowing that the October release follows the RES and RBJ conventions. Also, should I be expecting the October release soon (today is 10/21/92) or is that a question for Developer Services (if so can you give me the phone number again?) Thanks, --Paul There is 1 Reply. #: 15526 S7/Tools-Microsoft 21-Oct-92 12:32:58 Sb: #15510-Dialog Editor Fm: Paul Tissue [Microsoft] 70744,24 To: Paul Ligeski 76636,1166 (X) Hello Paul, With over 25,000 kit that must be manufactured and shipped it will take us a couple weeks to pull this off. Please ask the folks in section 1: "Non-tech Cust. Serv." for further details; us technical support engineers are typically not informed about such marketing issues. - Paul, Win32 SDK Developer Support #: 15534 S7/Tools-Microsoft 21-Oct-92 13:16:02 Sb: Beta mip2coff error Fm: Martin Heller 74000,2447 To: Andy Thomas 73650,50 I just installed a MIPS Magnum and put the Beta on it. When I try to build my C programs I get: mip2coff -c *.obj fatal: unsupported language found in file (language code 6) I'm a little surprised -- I built these same programs with the same make files last week on another MIPS machine running build 3.23. Any ideas? I don't even know where to start. There is 1 Reply. #: 15549 S7/Tools-Microsoft 21-Oct-92 14:38:18 Sb: #15534-Beta mip2coff error Fm: Martin Heller 74000,2447 To: Martin Heller 74000,2447 (X) Arggh. I found my problem--a change I made to a master make file for Intel had the effect of suppressing the -g2 flag for MIPS. All better now. For future reference, language code 6 from mip2coff means you forgot the -g2 switch. #: 15427 S7/Tools-Microsoft 20-Oct-92 00:43:15 Sb: Problems debugging C++ p Fm: Centre File 100015,3565 To: all I'm trying to develop C++ classes on NT. I have just got a first cut port of my GUI library set compiled and built, to test my HELLO WORLD program. I have encountered two problems: 1. At the end of the link phase, the linker invokes CVPACK. CVPACK then falls over with the message 'The instruction at "0x00011644" referenced memory at "0x00000108". The memory could not be read. 2. I tried renaming CVPACK, so that it wouldn't get found at the link stage. This left me with a .exe (albeit a big one!). I then found that the debugger (windbg) didn't seem to get any symbols from the .exe when loaded. The upshot of this being that I can't debug my programs! Could anybody tell me if windbg works with C++ programs at all? If so, should it recognise unpacked .exe formats? If it has to be packed, is there a fix available for CVPACK? Incidently I'm using '-debug:notmapped,full' option with type set to 'cv' And finally, does anyone have an inkling of the latest beta release date? Thanks in advance for any assitance Stuart A. Murray #: 15566 S7/Tools-Microsoft 21-Oct-92 16:53:19 Sb: #15427-Problems debugging C++ p Fm: Doug Olson [Microsoft] 72350,2635 To: Centre File 100015,3565 (X) Stuart: Sorry to hear that you have ran into problems debugging. We have seen the memory error occur when CVPACKing large applications. To work around this problem I suggest compiling with debug information in only the modules that you need to debug. This will cut down the amount of information that CVPACK needs to process. As a last resort, I suggest compiling with the -Zd switch instead of -Zi. This switch will provide only line number information, but should allow you to CVPACK successfully. The current (July) version of WINDBG does not support C++ symbols. You can debug a C++ application, but it will not understand the decorated C++ symbol names. The October WINDBG will support C++ debugging. Please let me know if you are unable to work around the CVPACK problem. The October release of CVPACK should correct this problem. Sincerely, Doug Olson Microsoft Developer Support #: 15578 S7/Tools-Microsoft 21-Oct-92 21:38:22 Sb: Err Linking C & C++ Fm: Jim Young 72760,725 To: Sysop (X) I trying to compile and link an application with cl386 and COFF and I'm encountering a problem. The application is composed of both C and C++ object modules. I'm getting errors during the link indicating that global symbols that are defined in the C++ modules and referenced in the C modules are NOT defined in the C modules (my.obj : warning 0516 _szPath is undefined). Apparently things are working the other way, IOW globals defined in C modules are accessable in C++ modules. Is this a known problem? I've tried declaring them as extern "C" but this does not work and also makes them unaccessable to any other C++ modules. Help! --Jim #: 15465 S7/Tools-Microsoft 20-Oct-92 12:42:12 Sb: Casting and addition Fm: Marc Singer 72130,2546 To: Sysop (X) I seems to me that this is not appropriate behavior. unsigned a, b, c; a = 1; b = 2; c = 3; if (a < b + c) /* Generates a warning */ ... I receive a warning about comparing signed and unsigned numbers. The code is OK if I cast this way: if (a < (unsigned) (b + c)) ... But, I don't think that the addition of two unsigned values should demote the type to signed. So, tell me. What's the right way? The current rule make my code much less readable. Marc Singer -- Straylight Software #: 15576 S7/Tools-Microsoft 21-Oct-92 21:20:51 Sb: #15465-Casting and addition Fm: Doug Olson [Microsoft] 72350,2635 To: Marc Singer 72130,2546 (X) Marc: Thanks for reporting this problem. You should not be receive a warning from the code you provided. This problem has been corrected in the October SDK. Sincerely, Doug Olson Microsoft Developer Support There is 1 Reply. #: 15588 S7/Tools-Microsoft 22-Oct-92 02:53:21 Sb: #15576-Casting and addition Fm: Marc Singer 72130,2546 To: Doug Olson [Microsoft] 72350,2635 (X) Well, that's the thing. This has not been corrected in the October release. I have it and I receive the same error message I have always received. In fact, I am finding some new problems with the development tools that were not previously there (or I have not yet discovered). I posted other messages about these troubles earlier in the week. So, has it been fixed or not? Will it be fixed if it has not already been? Marc Singer -- Straylight Software There is 1 Reply. #: 15614 S7/Tools-Microsoft 22-Oct-92 12:33:11 Sb: #15588-Casting and addition Fm: Doug Olson [Microsoft] 72350,2635 To: Marc Singer 72130,2546 (X) Marc: I cannot reproduce this warning with the Oct. Compiler. In fact, I compiled the same sample using the July release and did not receive the warning. I believe the difference may be our compiler switches, would you provide me with yours? To make things even more generic, I striped my sample down to the following: void main(void) { unsigned a,b,c; a=1; b=2; c=3; if(a < b + c) a=b; } Please note that there are no include files. I compiled with the following command: CL386 -c -Od -W5 test.c And did not receive any warning or errors. Please give this a try, if you do not get the warning you can build back up to what you previously had and see where the warning is introduced. Please let me know what happens. Sincerely, Doug Olson Microsoft Developer Support #: 15325 S7/Tools-Microsoft 18-Oct-92 03:27:02 Sb: Librarian error (COMDAT) Fm: Brad Hines 76520,3314 To: Sysop (X) I have managed to get my project to successfully compile under Windows NT, but now I am having a problem with the librarian. The majority of my object files have the following problem. Does anyone know what this means or what a workaround is? Thanks, Brad ================================= Example CL386 and LIB runs follow ================================= E:\winpp\nt>cl386 -c -G3d -W3 -Di386=1 -Zi -Od -DWIN32 -DSTRICT /Foobj\mdimain.obj mdimain.cpp mdimain.cpp E:\winpp\nt>LIB -out:winpp.lib obj\mdimain.obj Microsoft(R) Windows NT Librarian Version 2.10 (C) 1989-1992 Microsoft Corp. All rights reserved. cvtomf() : error : continuation of COMDAT not supported yet obj\mdimain.obj() : error 0123: Can't convert object to Windows NT format There are 2 Replies. #: 15379 S7/Tools-Microsoft 19-Oct-92 13:29:45 Sb: #15325-Librarian error (COMDAT) Fm: Doug Olson [Microsoft] 72350,2635 To: Brad Hines 76520,3314 (X) Brad: I will find out what causes this error. Sincerely, Doug Olson Microsoft Developer Support #: 15467 S7/Tools-Microsoft 20-Oct-92 12:51:18 Sb: #15325-Librarian error (COMDAT) Fm: Doug Olson [Microsoft] 72350,2635 To: Brad Hines 76520,3314 Brad: This error is caused by large in-line functions. The record that is currently used to instantiating an in-line function has a limit of 955 bytes. Please try reducing the size of your larger in-line functions to see if the problem corrects. This limit should go away in later releases of the compiler. Please let me know if this solves the problem. Sincerely, Doug Olson Microsoft Developer Support #: 15586 S7/Tools-Microsoft 22-Oct-92 01:26:36 Sb: #15467-Librarian error (COMDAT) Fm: Brad Hines 76520,3314 To: Doug Olson [Microsoft] 72350,2635 (X) Doug, I carefully examined my code, and my largest inline function consisted of a 3-liner which did one subroutine call (not to an inline function) and two assignments. So, I once again began whittling my code away until I came up with the sample code that I am uploading as LIBBG3.ZIP. Basically, the problem appears to occur when there are more than 150 virtual functions in a class. The readme file gives more detail. Unfortunately, this is functionality that I don't think I can do without for my program. I can eliminate some of the virtual functions for the time being, but I will need more and more of them as time goes on, so I will definitely be waiting on the edge of my chair for an update if there's any way to get one to me any time soon. Hopefully we'll hit the bottom of this well of problems soon :). Thanks for your time and trouble, Brad There is 1 Reply. #: 15615 S7/Tools-Microsoft 22-Oct-92 12:33:15 Sb: #15586-Librarian error (COMDAT) Fm: Doug Olson [Microsoft] 72350,2635 To: Brad Hines 76520,3314 (X) Brad: Thanks for putting together a sample, I will retrieve it now. I will forward it to our Language Development team and let you know the outcome. Sincerely, Doug Olson Microsoft Developer Support #: 15538 S7/Tools-Microsoft 21-Oct-92 13:33:51 Sb: C compiler bug Fm: Jeff Robbins 70303,1570 To: Microsoft To Microsoft, Here's a makefile, c file, and asm output. The asm code is wrong. It looks like the compiler noticed something clever here, like all it had to do was compare ah to 9, but the asm code cmp eax to 9, not at all what the c code says. We don't know if the .obj code is right or not. Jeff Robbins Cycle Software, Inc. all: cl386 -c -Gs -W2 -nologo -Fa shift.c main () { unsigned num; unsigned x; num = 1388; if (((unsigned char) ((num & 0x00000F00) >> 8)) > 9) x = num; else x = num + 1; } TITLE shift.c .386P include listing.inc _TEXT SEGMENT DWORD USE32 PUBLIC 'CODE' _TEXT ENDS _DATA SEGMENT DWORD USE32 PUBLIC 'DATA' _DATA ENDS CONST SEGMENT DWORD USE32 PUBLIC 'CONST' CONST ENDS _BSS SEGMENT DWORD USE32 PUBLIC 'BSS' _BSS ENDS FLAT GROUP _DATA, CONST, _BSS ASSUME CS: FLAT, DS: FLAT, SS: FLAT PUBLIC _main EXTRN __acrtused:NEAR _TEXT SEGMENT DWORD USE32 PUBLIC 'CODE' ; File shift.c _num$ = -8 _x$ = -4 _main PROC NEAR ; Line 2 push ebp mov ebp, esp sub esp, 8 push ebx push esi push edi ; Line 7 mov DWORD PTR _num$[ebp], 1388 ; 0000056cH ; Line 9 mov eax, DWORD PTR _num$[ebp] and eax, 3840 ; 00000f00H cmp eax, 9 jle $L109 ; Line 10 mov eax, DWORD PTR _num$[ebp] mov DWORD PTR _x$[ebp], eax ; Line 11 jmp $L110 $L109: ; Line 12 mov eax, DWORD PTR _num$[ebp] inc eax mov DWORD PTR _x$[ebp], eax $L110: ; Line 14 $L106: pop edi pop esi pop ebx leave ret 0 _main ENDP _TEXT ENDS END There is 1 Reply. #: 15616 S7/Tools-Microsoft 22-Oct-92 12:33:20 Sb: #15538-C compiler bug Fm: Doug Olson [Microsoft] 72350,2635 To: Jeff Robbins 70303,1570 Jeff: Thanks for the report. I will examine the output and let you know what I find. Sincerely, Doug Olson Microsoft Developer Support #: 15618 S7/Tools-Microsoft 22-Oct-92 13:48:54 Sb: COFF out of memory error Fm: Brad Hines 76520,3314 To: Sysop (X) Hello. Unfortunately, it looks like I've run into yet another problem with COFF. There is one object file that I have that, when I try to link it or load it into a library, COFF aborts with an out of memory error. The object file is only about 40K in size. Does anyone know what's going on here? Thanks, Brad ===================================================== Sample LIB run: E:\winpp>lib -out:foo.lib msg.obj Microsoft(R) Windows NT Librarian Version 2.10 (C) 1989-1992 Microsoft Corp. All rights reserved. LIB() : error 0102: Out of memory Extended Error: No such file or directory #: 15319 S7/Tools-Microsoft 17-Oct-92 15:20:47 Sb: #15264-FAT file names Fm: Jeff Thomson 71460,3222 To: Dan Sullivan 76327,1534 (X) Dan, > My editor (CodeWright) will sometimes not be able to open a file that the > Open File common dialog it uses sees. I've been having the same problem w/ Codewright under NT, and have reported this and several other problems to Premia. They replied that the next release of NT should allow CW to run *much* better, as a number of NT developers are using CW, and *they* want it to run well as much as you and I do . > In fact is I run nmake with -p I can see the the inference rule properly > specifies the file, nmake won't use the inference file in NT, but it will > in DOS. I haven't seen this problem myself. One thing that I would recommend checking is the .SUFFIXES list under both NT and DOS (by redirecting the output of 'nmake -n -p' into a file, for example). My experience has been that when an inference rule isn't getting invoked, and you'd *swear* that it should be, the .SUFFIXES list is often the cause. Hope this helps. -- Jeff There is 1 Reply. #: 15327 S7/Tools-Microsoft 18-Oct-92 05:23:21 Sb: #15319-FAT file names Fm: Dan Sullivan 76327,1534 To: Jeff Thomson 71460,3222 (X) Thanks for the CW info, however the nmake problem has nothing to do with the suffixes being incorrect. I can run the same make file under DOS and it works fine. Also by using -n -p I can see the suffix list and the expanded inference rule, and it should be seeing the files to be built. There don't seem to be any tools for poking at what NT sees as file names and types, I that is the only kind of problem I can think of that might be causing this response from NT. Dan #: 15624 S7/Tools-Microsoft 22-Oct-92 13:56:53 Sb: #15264-FAT file names Fm: Colin Stuart [Microsoft] 70744,25 To: Dan Sullivan 76327,1534 (X) Dan, I'm looking into this. Colin #: 15625 S7/Tools-Microsoft 22-Oct-92 13:56:58 Sb: Nested CTLS in DLGEDIT Fm: Colin Stuart [Microsoft] 70744,25 To: neil colvin 71650,3517 (X) Neil, I'll forward your suggestion to the DlgEdit developer. Colin #: 15628 S7/Tools-Microsoft 22-Oct-92 14:01:54 Sb: WinDbg Fm: Howard Myers 76711,462 To: Microsoft I'm having major problems with WinDbg. (October Beta release) The July release wouldn't let me load some source files -- no errors, they just won't load. This problem was reported quite a while ago, but unfortunately is not fixed in the beta. Now to make matters worse, there is a new bug that won't let me set breakpoints in my code. I have at least one file that loads into WinDbg, but it won't let me set breakpoints on any lines in the file. It was compiled with the /Zi option and has been properly linked (as attested to by the fact that other files don't have this problem). It is also in sync with the .EXE file, not an old version. I recompiled all the files when I got the beta release. Any ideas how to avoid/fix either of these? I'm getting less and less done as I can debug less and less code without the use of breakpoints! #: 15638 S7/Tools-Microsoft 22-Oct-92 15:16:29 Sb: MS Knowledge Base Fm: Colin Stuart [Microsoft] 70744,25 To: ALL The following list consists of titles and unique identifiers of Win32 SDK technical articles contained in the Microsoft Knowledge Base used by Microsoft support staff. For access to the most up-to-date information, access the Microsoft Knowledge Base by typing 'go mskb' at the prompt. A feedback-only email alias has been set up to take any comments on the Microsoft Knowledge Base: 'y-kbfeed@microsoft.com' Thank you. -----------------------------------------------------------------------INF: OS/2-to-Windows Migration Information [P_W32dev] Q89058 -----------------------------------------------------------------------SDK9209: ScrollConsoleScreenBuffer Scrolls Foreground Buffer [P_W32dev] Q89372 -----------------------------------------------------------------------INF: Replacing the Windows NT Task Manager [P_W32dev] Q89373 -----------------------------------------------------------------------INF: Byte-Ordering in a Data Packet Under NDIS [P_W32dev] Q89374 -----------------------------------------------------------------------INF: Transparent Blts in Windows NT [P_W32dev] Q89375 -----------------------------------------------------------------------INF: How to Specify Shared and Nonshared Data in a DLL [P_W32dev] Q89817 -----------------------------------------------------------------------INF: Writing Multiple-Language Resources [P_W32dev] Q89866 -----------------------------------------------------------------------INF: Using DocumentProperties() Instead of ExtDeviceMode() [P_W32dev] Q89867 -----------------------------------------------------------------------INF: Background Information on POSIX and XPG [P_W32dev] Q89899 -----------------------------------------------------------------------INF: System Error 2: ERROR_FILE_NOT_FOUND [P_W32dev] Q89988 -----------------------------------------------------------------------INF: CreateFile() Using CONOUT$ or CONIN$ [P_W32dev] Q90088 [More] There is 1 Reply. #: 15639 S7/Tools-Microsoft 22-Oct-92 15:16:35 Sb: #15638-MS Knowledge Base Fm: Colin Stuart [Microsoft] 70744,25 To: Colin Stuart [Microsoft] 70744,25 (X) [Continued] -----------------------------------------------------------------------SDK9210: MS-DOS-Basedand WOW Applications Won't Run on PS/2s [P_W32dev] Q90501 #: 15551 S7/Tools-Microsoft 21-Oct-92 14:47:08 Sb: C and C++ linkage Fm: Christian Betrisey 76600,1450 To: Microsoft What are the (major) differences between C linkage and C++ linkage in C 7 ? There is 1 Reply. #: 15655 S7/Tools-Microsoft 22-Oct-92 17:29:54 Sb: #15551-C and C++ linkage Fm: Doug Olson [Microsoft] 72350,2635 To: Christian Betrisey 76600,1450 (X) Christian: The most important thing that I believe you should be aware of is that we decorate our C++ symbols. This allows type safe linkage, where functions with the same name will never be mistaken for one other. For a very detailed description of how linkage is achieved with C7, I suggest reading the following pages: C Language Reference page 34-39 C++ Language Reference page 33-37 I am going to leave you with this since linkage is such a broad topic. If you have specific questions about certain types of linkage (such linkage in names of a particular scope) I'd be happy to answer them. Sincerely, Doug Olson Microsoft Developer Support #: 15574 S7/Tools-Microsoft 21-Oct-92 19:50:41 Sb: DLL/FP/Linker Fm: Doug Olson [Microsoft] 72350,2635 To: Julius Oklamcak 76004,2246 (X) Julius: Thanks for waiting, this problem has been interesting. To prevent the linker from attempting to resolve _main, use -entry:_CRT_INIT on your DLL link line. Also, please make sure to define _MT (-D_MT on the CL386 command line) when compiling. When you upgrade to the October SDK, you will need to change -entry:_CRT_INIT to -entry:_CRT_INIT@12. Please let me know if you have any further problems or questions. Sincerely, Doug Olson Microsoft Developer Support There is 1 Reply. #: 15663 S7/Tools-Microsoft 22-Oct-92 17:37:47 Sb: #15574-DLL/FP/Linker Fm: Julius Oklamcak 76004,2246 To: Doug Olson [Microsoft] 72350,2635 (X) Thanks, Doug, I'll pass it on... #: 15476 S7/Tools-Microsoft 20-Oct-92 13:43:03 Sb: Exporting C++ Names Fm: Keith MacDonald 100041,235 To: SYSOP (X) I'm trying to create a DLL from my C++ source that works fine in Windows 3.1. My problem is that I need to specify the exported names in my .DEF file, in their decorated form, so that COFF can generate a .EXP file. I've tried two approaches to getting the decorated names: 1) Link my application and use the names from the undefined externals error messages. 2) Extract the names from the .OBJ file for the DLL. In either case, I get "_name is undefined" messages for each "name" I export in the .DEF file, whenever I get COFF to link my DLL. Can somebody PLEASE help me? #: 15665 S7/Tools-Microsoft 22-Oct-92 17:54:45 Sb: #15476-Exporting C++ Names Fm: Doug Olson [Microsoft] 72350,2635 To: Keith MacDonald 100041,235 (X) Keith: This is a known problem with COFF. It is adding a leading underscore to the exported symbol names. Let me look into this further and get back with you. Sincerely, Doug Olson Microsoft Developer Support #: 15375 S7/Tools-Microsoft 19-Oct-92 12:10:17 Sb: CVW3 under NT? Fm: Michael Ward 71053,3717 To: all Is it possible to run codeview for windows under NT? I'm trying to get my Windows application to run under WOW in NT. It comes very close but segs in a couple of places. I suspect that these may be problems in my code but without a source level debugger it is hard to tell. Any suggestions? By the way this is the October release of Win NT. There are 2 Replies. #: 15421 S7/Tools-Microsoft 19-Oct-92 22:56:24 Sb: #15375-CVW3 under NT? Fm: Bill Cohagan 74375,313 To: Michael Ward 71053,3717 (X) Michael- | ... Any suggestions? By the way this |is the October release of Win NT. ^^^^^^^^^^^^^^^^^^^^^^^^^ Did you really mean that? Be careful now -- you don't want to start a riot! Seriously, if you have the October release, I'd be interested to know when/how you got it. Thanks, Bill #: 15422 S7/Tools-Microsoft 19-Oct-92 23:26:37 Sb: #15375-CVW3 under NT? Fm: Doug Olson [Microsoft] 72350,2635 To: Michael Ward 71053,3717 (X) Michael: Unfortunately Codeview for Windows will not run under WOW. I can only suggest more traditional methods of debugging, such as using output to trace the execution. Sincerely, Doug Olson Microsoft Developer Support There is 1 Reply. #: 15437 S7/Tools-Microsoft 20-Oct-92 05:47:48 Sb: #15422-CVW3 under NT? Fm: Michael Ward 71053,3717 To: Doug Olson [Microsoft] 72350,2635 (X) Well Doug, that's an interesting answer. In all this hoop-pa-la about NT running DOS apps in never occured to anyone that someone might need to run a source-level debugger on 16 bit code? I was kind-of hoping that I'd be able to develop 16bit windows under NT where I would have a protected environment and all. Guess I just shot that in the foot. I'll give one example of why this is so important. The SetTimer() call in Windows 3.1 will accept 0 as a timer ID. Windows NT will not. What is even worse, is WOW will not accept 0 as a valid timer ID. So here I have perfectly acceptable code that runs under 3.1 but won't run under WOW or as a native NT app. The documentation for NT does not say 0 is an invalid value for a timer ID. I found this bug using "traditional" methods and it only took about 2.5 hours. Something that would of taken 2.5 minutes had I had a source-level debugger. Can Microsoft really be serious about running 16 bit apps without some type of source-level debugger support? There is 1 Reply. #: 15470 S7/Tools-Microsoft 20-Oct-92 13:22:39 Sb: #15437-CVW3 under NT? Fm: Marc Singer 72130,2546 To: Michael Ward 71053,3717 Doug, I, too, feel that we will need some debugging tools for Windows 3.1 apps running as NT clients. My current project runs as both a Windows NT and a Windows 3.1 application. In the October build, I am still finding some sticky errors in the WOW subsystem's emulation. Though this version is significantly better than the July release, I could benefit tremendously from a debugger that shows me exactly why some of the dysfunctional behaviors occur. Marc Singer -- Straylight Software #: 15559 S7/Tools-Microsoft 21-Oct-92 15:28:55 Sb: #15470-CVW3 under NT? Fm: Doug Olson [Microsoft] 72350,2635 To: Marc Singer 72130,2546 (X) Marc: Thanks for the suggestion. I will forward your comments on and keep you informed of any new information on this topic. (see previous message) Sincerely, Doug Olson Microsoft Developer Support #: 15541 S7/Tools-Microsoft 21-Oct-92 13:57:10 Sb: #15437-CVW3 under NT? Fm: Doug Olson [Microsoft] 72350,2635 To: Michael Ward 71053,3717 (X) Michael: Thanks for all your input on this topic. >>In all this hoop-pa-la about NT running DOS apps it never occured to anyone that someone might need to run a source-level debugger on 16 bit code? We are very aware of this issue. The problem you had with SetTimer is a good example of a situation where a 16-bit debugger would have been very useful. I currently don't know the exact cause of the problem or the details behind running the 16-bit CVW inside WOW. A debugger, of course, is not a typical 16-bit application. I will look further into this issue and post any useful information here. I have also forwarded your comments on to our Language Program Management. Sincerely, Doug Olson Microsoft Developer Support There is 1 Reply. #: 15591 S7/Tools-Microsoft 22-Oct-92 05:00:46 Sb: #15541-CVW3 under NT? Fm: Michael Ward 71053,3717 To: Doug Olson [Microsoft] 72350,2635 (X) I wonder if it would be possible to write an NT hosted debugger that could work on 16 bit code? I realize that debuggers are radical programs in an operating system sense but having the 16 bit debuggers running under NT-DOS emulation would be one heck of a benchmark to aim for. I hold high hopes for NT as a host environment for development of Windows, OS/2, and of course NT apps. But for now it still remains something of a toy. Also, next release lets get some SuperVGA drivers guys. The few that are on there don't work on my Gateway and the MIPS (R4000) is even worse. There is 1 Reply. #: 15666 S7/Tools-Microsoft 22-Oct-92 17:54:50 Sb: #15591-CVW3 under NT? Fm: Doug Olson [Microsoft] 72350,2635 To: Michael Ward 71053,3717 (X) Michael: Yes, it would be possible to write a NT hosted debugger that could debug 16-bit DOS/Windows applications, it would most likely be a Win32 application. Having the existing 16-bit debugger work under NT WOW is, however, a different problem. WOW does not currently support the debugging APIs needed to run CVW. Sincerely, Doug Olson Microsoft Developer Support #: 15567 S7/Tools-Microsoft 21-Oct-92 16:55:36 Sb: #15437-CVW3 under NT? Fm: Graham Welland 70023,1267 To: Michael Ward 71053,3717 (X) Michael, Were you waiting for that idea of the ideal NT product???? Well, I guess a source level debugger might just fit the bill. A trek along to the Device Driver Developer conference could pay back handsomely for somebody. The only thing to look out for is MS secretly working on one, and then giving it away free to all NT developers in the future :( Graham There is 1 Reply. #: 15592 S7/Tools-Microsoft 22-Oct-92 05:04:49 Sb: #15567-CVW3 under NT? Fm: Michael Ward 71053,3717 To: Graham Welland 70023,1267 Graham, Interesting idea about the debugger but I'm just not that much of a system nut. Also, I have my hands quite full with work on two other plateforms. Ah, if it were as easy as saying "Make it so!", like they do on Star Trek. I don't think programmers will go wanting for a job anytime soon. #: 15431 S7/Tools-Microsoft 20-Oct-92 02:19:39 Sb: Porttool Fm: Simon Moore 100014,1357 To: Simon Moore 100014,1357 (X) Correction to my previous message - I did find the WIN32API.DAT file, and added a line to WIN.INI as instructed in ch5 of ProgTech, but PORTTOOL does not seem to be taking any notice - any ideas? (I must admit, I'm slightly confused about updating WIN.INI as everything else I've seen implies that you cannot just go and edit INI files but I'm not sure what else you are supposed to do.) Thanks #: 15548 S7/Tools-Microsoft 21-Oct-92 14:35:28 Sb: #15431-Porttool Fm: Cameron Ferroni [MS] 72360,2300 To: Simon Moore 100014,1357 (X) PORTTOOL uses the PORT.INI file, not the WIN32API.DAT file, which is provided only as a reference. If you have made changes to WIN32API.DAT, then see the PORT.INI for comments on how to incorporate your changes. -Cam There is 1 Reply. #: 15595 S7/Tools-Microsoft 22-Oct-92 08:30:36 Sb: #15548-Porttool Fm: Simon Moore 100014,1357 To: Cameron Ferroni [MS] 72360,2300 (X) There is no sign of PORT.INI on my installation or the CDRom (July 92 version). Any ideas? #: 15623 S7/Tools-Microsoft 22-Oct-92 13:56:48 Sb: Porttool Fm: Colin Stuart [Microsoft] 70744,25 To: Simon Moore 100014,1357 (X) Simon, The dat file is \mstools\bin\win32api.dat. The FIND utility, in the \system directory, is a good tool for locating files in a tree structure. Colin There is 1 Reply. #: 15671 S7/Tools-Microsoft 23-Oct-92 05:49:19 Sb: #15623-Porttool Fm: Simon Moore 100014,1357 To: Colin Stuart [Microsoft] 70744,25 (X) Thanks. As I said in my subsequent message, I have found it, but don't seem to be able to get PORTTOOL to find it. The lines I added to WIN.INI seem to be ignored. #: 15550 S7/Tools-Microsoft 21-Oct-92 14:42:04 Sb: WINDBG (COMDEX/MS!) Fm: Bill Carswell 74230,3710 To: MICROSOFT COMDEX MICROSOFT BOOTH TIME SENSITIVE Several developers in our conversion group are having difficulty with WINDBG. In particular, we are unable to set breakpoints without getting an 'uninstantiated breakpoint' message. Also, the locals and watch windows do not consistently work. We get locals in some functions and not in others. Watch does not want to watch most variables. All modules have been compiled with -Zi. Are we omitting a preparation step or is WINDBG just not ready for prime time yet? Thanks for your help! There are 2 Replies. #: 15637 S7/Tools-Microsoft 22-Oct-92 15:15:56 Sb: #15550-WINDBG (COMDEX/MS!) Fm: Kevin Quinn 75430,255 To: Bill Carswell 74230,3710 (X) Bill - Are you using the JulyJunk, or the new OctoberSuprise? I'm asking 'cause we're loading the 'real beta', and windbg is gonna be _real_ important to us also... Kevin Quinn Desktop Systems Ingres There is 1 Reply. #: 15678 S7/Tools-Microsoft 23-Oct-92 07:20:24 Sb: #15637-WINDBG (COMDEX/MS!) Fm: Bill Carswell 74230,3710 To: Kevin Quinn 75430,255 (X) We are using the July version and anxiously? waiting for the Octoberfest version. We have since found that the only reliable way to set breakpoints is by using the hand on the toolbar. The bp command and the breakpoints dialog are not yet reliable. Still waiting for news about the watch and locals windows. #: 15649 S7/Tools-Microsoft 22-Oct-92 17:23:24 Sb: #15550-WINDBG (COMDEX/MS!) Fm: Colin Stuart [Microsoft] 70744,25 To: Bill Carswell 74230,3710 (X) Bill, Are you compiling with /Od? I assume that you're building on the October release. If you have any optimizations on, It can seriously confuse debuggers. -Colin #: 15461 S7/Tools-Microsoft 20-Oct-92 12:11:11 Sb: NT CL386 Compiler Errors Fm: Steve Milton 70760,1665 To: all I have recently installed the NT SDK but I am having problems compiling the GENERIC Sample. I get the following error: fatal error c1001: Internal Compiler Error (Compiler file 'msc1.cpp', line 555) Contact Microsoft Product Support Services Please help, i cannot get anything to compile. #: 15490 S7/Tools-Microsoft 20-Oct-92 15:53:59 Sb: #15461-NT CL386 Compiler Errors Fm: Cameron Ferroni [MS] 72360,2300 To: Steve Milton 70760,1665 (X) The problem is with the SETENV.BAT file. It tries to prepend new environment variables onto old ones, but if there are no old ones, it leaves a ; at the end of the environment variable, which causes the compiler error: set Include=c:\mstools\h;% There is 1 Reply. #: 15669 S7/Tools-Microsoft 22-Oct-92 18:49:59 Sb: #15490-NT CL386 Compiler Errors Fm: Steve Milton 70760,1665 To: Cameron Ferroni [MS] 72360,2300 (X) I tried to set the include statement as you suggested, then I ran the setenv.bat file. I got exactly the same message. I checked the set list, and the include statement looked fine, i.e. no ; at the end. I still don't get it. There is 1 Reply. #: 15686 S7/Tools-Microsoft 23-Oct-92 10:17:04 Sb: #15669-NT CL386 Compiler Errors Fm: Cameron Ferroni [MS] 72360,2300 To: Steve Milton 70760,1665 How about the Lib variable? Acutally, what you really should do is the following: Start up the Control Panel. Choose the System applet. Within the system applet set the following in the User Variables section, assuming an x86 machine with the SDK installed into C:\MSTOOLS: Cpu = i386 Include = c:\mstools\h;c:\mstools\mfc\include Path = c:\mstools\bin Lib = c:\mstools\lib;c:\mstools\mfc\lib You must then log off and log back on, but you will never have to set the variables again. #: 15533 S7/Tools-Microsoft 21-Oct-92 13:05:18 Sb: #15461-NT CL386 Compiler Errors Fm: Cameron Ferroni [MS] 72360,2300 To: Steve Milton 70760,1665 (X) Sorry, this is my first time replying. Anyways, the problem was that setenv.bat leaves ; at the end of the environment variables. The best way to avoid this is to set the user environment variables in the Systems applet in the Control Panel. #: 15486 S7/Tools-Microsoft 20-Oct-92 15:03:02 Sb: Beta and windbg question Fm: Kevin Quinn 75430,255 To: Microsoft Yo, Microsoft types: We're installing the October Beta on a 'spare' machine for evaluation. Before we consider installing it _quickly_ on our production machines and recompiling all 3 thousand or so files, can you tell me if windbg has in fact been fixed up? Of most immediate interest is can the sob show local variables way down in the guts of a large program? (it can't currently). Any insights greatly appreciated. Kevin Quinn Desktop Systems Ingres #: 15648 S7/Tools-Microsoft 22-Oct-92 17:23:19 Sb: #15486-Beta and windbg question Fm: Colin Stuart [Microsoft] 70744,25 To: Kevin Quinn 75430,255 (X) Kevin, I haven't encountered any problems with watching local variables in the October release of WinDbg. It is much more robust than the July release, but probably not 100% bug-free; hence the term 'beta.' :) -Colin There is 1 Reply. #: 15694 S7/Tools-Microsoft 23-Oct-92 11:06:52 Sb: #15648-Beta and windbg question Fm: Kevin Quinn 75430,255 To: Colin Stuart [Microsoft] 70744,25 (X) Colin - Thanks for the response. Believe me - I understand 'beta'. My principal concern was driven by the degredation of the debugging tools at each release - any world be truly up the creek... ONce we get the new compiler to shut seems somewhat stricter - and I compile and link a couple thousand files, I'll give it a shot. Now if I can only crack the seeming bug in _ftol on the fistp instruction.... Kevin Quinn Desktop Systems Ingres #: 15643 S7/Tools-Microsoft 22-Oct-92 15:56:20 Sb: Sockets Fm: Carl Ziglin 76550,123 To: MS Support We are trying to use Sockets with Win 3.1. We took the WINSOCK.LIB and WINSOCK.DLL from our NT SDK & tried to link with the .LIB. We got the following link error: LINK : fatal error L1104: e:\windev\lib\winsock.lib : not valid library Does this mean that we need a WIN 3.1 version of WINSOCK.LIB and WINSOCK.DLL? If so, where do we get these? Thanks for the help, Carl There is 1 Reply. #: 15695 S7/Tools-Microsoft 23-Oct-92 11:07:57 Sb: #15643-Sockets Fm: David Taniguchi [MS] 72350,2054 To: Carl Ziglin 76550,123 Hi Carl, >Does this mean that we need a WIN 3.1 version of WINSOCK.LIB and WINSOCK.DLL? Yes. >If so, where do we get these? Third party vendors. Off the top of my head, I believe Frontier Technologies, Distinct, NetManage and others are working on implementations. However, none of them are considered "Windows Sockets Compliant" until after the conformance testing conducted before Interop and the specification will be revised based on input given there. You can get a "feel" for the winsock specific calls (WSA calls) with what is provided in the SDK. If you have any further questions concerning Winsock, please post in Section 12 (API-RPC/WinNet). Hope this helps, Dave #: 15381 S7/Tools-Microsoft 19-Oct-92 13:49:09 Sb: #15244-RC Anomaly Fm: David Taniguchi [MS] 72350,2054 To: Samuel Feldman 70403,432 Hi Samuel, Here is some info: An accelerator table is stored as a single resource. Multiple accelerator tables are also allowed. The format of an accelerator table is very simple. No header for the table is used. Each entry in the table has a single five byte entry. The last entry in the table has its flag word high bit set (fFlags |= 0x8000). Since all entryies are fixed length, random access can be done because the number of elements in the table can be computed by dividing the length of the resource by eight. Hope this helps, Dave #: 15503 S7/Tools-Microsoft 20-Oct-92 22:47:01 Sb: #15381-RC Anomaly Fm: Samuel Feldman 70403,432 To: David Taniguchi [MS] 72350,2054 (X) David, >> Each entry in the table has a single five byte entry. The last entry in >> the table has its flag word high bit set (fFlags |= 0x8000). This ain't right. In Win32, each entry is eight bytes. Also, the flag word seems to use 0x0080 instead of 0x8000. Take a look at a .RES file if you don't believe me. So, my question is still outstanding: is the format of the flags a bug? -- Samuel There is 1 Reply. #: 15697 S7/Tools-Microsoft 23-Oct-92 11:08:07 Sb: #15503-RC Anomaly Fm: David Taniguchi [MS] 72350,2054 To: Samuel Feldman 70403,432 (X) Hi Samuel, I am checking into this. Will post more later. Thanks Dave #: 15698 S7/Tools-Microsoft 23-Oct-92 11:12:15 Sb: Portable .EXE format Fm: Samuel Feldman 70403,432 To: Sysop (X) Hello MS -- Can you tell me if the Portable Executable file format is published, or going to be published? I need to update resources in PE-format .EXE files. I realize that there are functions to do this in the Win32 API (UpdateResource, etc.). However, I need to also be able to do this from a DOS program or from a NT console command-line program. An even better way to accomplish this of course would be for MS to provide a library that could be linked into a program that would contain the equivalent of the Win32 API functionality for updating resources. Or if MS were to publish the code that implements that part of the API, then it could be fairly easily massaged into library format by people like me. I'll take whatever I can get, needless to say! Can you help? -- Samuel #: 15630 S7/Tools-Microsoft 22-Oct-92 14:34:02 Sb: Default Arg Values Fm: David J. Plunkett 71163,2122 To: Microsoft // With the October release, this program fails. // The value of a.c should be 3.0, not 1.0. // This worked in the July release of NT. // We are hoping to demo at Autofact and Comdex using the new NT // release. This may be impossible if this bug isn't fixed. #: 15708 S7/Tools-Microsoft 23-Oct-92 12:04:40 Sb: #15630-Default Arg Values Fm: Paul Tissue [Microsoft] 70744,24 To: David J. Plunkett 71163,2122 (X) Hello David, Thank you for reporting this bug. We have verified the problem with default argument initialization with the October release and are busy working on a solution. We will post additional information here. In the meantime, the workaround is to explicitly initialize the variables during instantiation. If you have other circumstance which makes this workaround difficult, if not impossible, then please indicate what those are. - Paul, Win32 SDK Developer Support #: 15464 S7/Tools-Microsoft 20-Oct-92 12:42:05 Sb: cvtres Fm: Marc Singer 72130,2546 To: Sysop (X) The resource conversion tool terminates when it reads a RES file that contains multiple dlginclude records. This was fine in the previous version of the tool, but now it will not work. I would like to have either the resource file format (so I can extract the records myself) or a new version of cvtres that does not have this problem. Or, the best solution would be to receive a simple work-around, but I will take whatever I can get. Marc Singer -- Straylight Software #: 15610 S7/Tools-Microsoft 22-Oct-92 12:31:34 Sb: #15464-cvtres Fm: David Taniguchi [MS] 72350,2054 To: Marc Singer 72130,2546 (X) Hi Marc, Have you tried using #include instead of dlginclude? >I would like to have either the resource file format (so I can extract >the records myself) .. I am looking into this. I'll post when I get more information. Thanks, Dave There is 1 Reply. #: 15636 S7/Tools-Microsoft 22-Oct-92 15:03:50 Sb: #15610-cvtres Fm: Marc Singer 72130,2546 To: David Taniguchi [MS] 72350,2054 (X) David, I use dlgedit to create dialog templates (separate) for each dialog. My master RC file includes them using #include statements. How else am I expected to do this? This is one of those problems that just does not occur in Windows 3.1. In the samples files, none of the dialogs appear to have been generated using this fragmentation scheme even though it has been the 'approved' technique since Windows 2.x. Marc Singer -- Straylight Software There is 1 Reply. #: 15670 S7/Tools-Microsoft 22-Oct-92 19:39:40 Sb: #15636-cvtres Fm: Paul Tissue [Microsoft] 70744,24 To: Marc Singer 72130,2546 (X) Hello Marc, The Debug Event Browser (DEB) includes a single separate DLG file which is #: 15712 S7/Tools-Microsoft 23-Oct-92 13:08:15 Sb: #15670-cvtres Fm: Marc Singer 72130,2546 To: Paul Tissue [Microsoft] 70744,24 (X) Paul, try this... === FOO.RC === #include #include "foo1.dlg" #: 15457 S9/CPU-x86 Specific 20-Oct-92 10:53:16 Sb: Re: CR3 & NT Fm: Hseuh-Lin Kung 72350,2426 To: NT Experts Dear NT Expert: Thanks for replying my question regarding the CR3 and NT. The CIS cleaned the message and I cannot remember your name, so... I think "NT Expert" is quite appropriate name for you. Let me answer the question why I need to know the information about if NT will change CR3 from time to time. We are considering turn on the busmaster and virtual memory mode of XGA coprocessor in our Windows 3.x (& NT) display driver. To keep the page table consistency, let the XGA's 2 way paging system shares the same page tables that NT provided seems a good idea. In that case, the most intuitive way to do it is to copy the content of the CR3 to PDBR (Page Dirctory Base Register) of XGA's, so XGA can reference the page table that NT provided. Ok, now, if the content of the CR3 will change from time to time, XGA has to keep track of the content of CR3 and update the PDBR in run time; if CR3 will not change, then we can simply copy that value in initilization. If the CR3 will not change, we will be very happy. If that is not the case, we are forced to write some kind of VxD service to get that information and suffer from the penalty of ring transition. Of course, there is an alternative way to do it: Microsoft can keep an updated CR3 value in a ring 3 variable, so we can access it directly without ring transition penalty. Only Microsoft can do this! I don't know if this will violate the security of the NT. Anyway, this is only a read operation, and you can hide it behind a server-clint protocol or something like. Since the NT DDK is not yet available, my suggestion is based on my understanding of Window 3.x. Probably there is a even better way to solve the question. What is your opinions and suggestions? Henri C. Chen Software Engineer ULSI Systems Inc. (408)943-0562 ext 254 #: 15517 S9/CPU-x86 Specific 21-Oct-92 09:31:53 Sb: #15457-Re: CR3 & NT Fm: David Taniguchi [MS] 72350,2054 To: Hseuh-Lin Kung 72350,2426 (X) Hi Henri, I am awaiting more feedback on your approach. Here are a few comments I have received. 1] You would have to modify the HAL or the memory manager to provide a copy of the page tables for the XGA. 2] Item 1 will not and should not be done on NT due to security and basic system stability issues. 3] With the ability to map a 4 meg aperture from the XGA directly into the linear address space of GDISRV the need for the bus mastership the XGA provides is questionable. 4] The XGA can not do GIQ correct lines, so the only thing we could hope to do would be some blit operations into host memory, directly into the users address space. I think the 486/586 is faster than the XGA when all the setup time is taken into account. If I get more information, i'll post here. If you have any comments or other ideas feel free to post. Thanks, Dave #: 15540 S9/CPU-x86 Specific 21-Oct-92 13:55:47 Sb: #15457-Re: CR3 & NT Fm: David Taniguchi [MS] 72350,2054 To: Hseuh-Lin Kung 72350,2426 (X) Hi Henri, I received another response. It is simply "We change CR3". Hope this helps, Dave #: 15451 S9/CPU-x86 Specific 20-Oct-92 09:54:12 Sb: Help on help Fm: Kenneth Gladden 72301,2627 To: sysop (X) I left a message here yesterday and it loks like someone cleaned house afterwards and deleted my message. Does that mean I am not going to get help with my install problems? There is 1 Reply. #: 15463 S9/CPU-x86 Specific 20-Oct-92 12:15:04 Sb: #15451-Help on help Fm: David Taniguchi [MS] 72350,2054 To: Kenneth Gladden 72301,2627 Hi Kenneth, This is the CPU-x86 specific section. General installs should go to section 3 of the WINNT forum, and SDK installs should go to section 2 of MSWIN32 forum. You might be looking in the wrong sections (which could be the source of confusion). Thanks, Dave #: 15573 S9/CPU-x86 Specific 21-Oct-92 19:14:14 Sb: #15463-Help on help Fm: Kenneth Gladden 72301,2627 To: David Taniguchi [MS] 72350,2054 (X) Thanks ... someone told me the same thing so I am now on WINNT forum. Sorry for the confusion! #: 15652 S9/CPU-x86 Specific 22-Oct-92 17:28:22 Sb: FYI: Knowledge Base Fm: David Taniguchi [MS] 72350,2054 To: All The following list consists of titles and unique identifiers of Win32 SDK technical articles contained in the Microsoft Knowledge Base used by Microsoft support staff. For access to the most up-to-date information, access the Microsoft Knowledge Base by typing 'go mskb' at the prompt. A feedback-only email alias has been set up to take any comments on the Microsoft Knowledge Base: 'y-kbfeed@microsoft.com' Thank you. -----------------------------------------------------------------------INF: OS/2-to-Windows Migration Information [P_W32dev] Q89058 -----------------------------------------------------------------------SDK9209: ScrollConsoleScreenBuffer Scrolls Foreground Buffer [P_W32dev] Q89372 -----------------------------------------------------------------------INF: Replacing the Windows NT Task Manager [P_W32dev] Q89373 -----------------------------------------------------------------------INF: Byte-Ordering in a Data Packet Under NDIS [P_W32dev] Q89374 -----------------------------------------------------------------------INF: Transparent Blts in Windows NT [P_W32dev] Q89375 -----------------------------------------------------------------------INF: How to Specify Shared and Nonshared Data in a DLL [P_W32dev] Q89817 -----------------------------------------------------------------------INF: Writing Multiple-Language Resources [P_W32dev] Q89866 -----------------------------------------------------------------------INF: Using DocumentProperties() Instead of ExtDeviceMode() [P_W32dev] Q89867 -----------------------------------------------------------------------INF: Background Information on POSIX and XPG [P_W32dev] Q89899 -----------------------------------------------------------------------INF: System Error 2: ERROR_FILE_NOT_FOUND [P_W32dev] Q89988 -----------------------------------------------------------------------INF: CreateFile() Using CONOUT$ or CONIN$ [P_W32dev] Q90088 [More] There is 1 Reply. #: 15653 S9/CPU-x86 Specific 22-Oct-92 17:28:27 Sb: #15652-FYI: Knowledge Base Fm: David Taniguchi [MS] 72350,2054 To: David Taniguchi [MS] 72350,2054 (X) [Continued] -----------------------------------------------------------------------SDK9210: MS-DOS-Basedand WOW Applications Won't Run on PS/2s [P_W32dev] Q90501 #: 15594 S9/CPU-x86 Specific 22-Oct-92 08:27:44 Sb: Multi processing NT Fm: Jeff Nuccio 76547,2342 To: 76547,2342 (X) To: Windows NT Product Support Group From : Anthony J. Campisi Company: Hauppauge Computer Works Inc. Phone: 516-434-1600 EXT 325 Fax: 516-434-3198 We at Hauppauge are Microsoft Windows NT developers. I was successful In installing WINDOWS NT on a Hauppauge MUTI-Processor computer (486DX50 x 3). However I can only run NT with a single 486 processor. I have the Microsoft Win32 Preliminary Software Development Kit for Windows NT. What I need is a Hardware Development kit or at least a architectural overview of what is required to do this Port for Muti-processors (inter-processor communication). I cannot find this type of information on the CD ROM. I would like to show three processor modules running Windows NT at COMDEX so I am in a rush. Thank you Anthony J. Campisi There are 2 Replies. #: 15611 S9/CPU-x86 Specific 22-Oct-92 12:31:39 Sb: #15594-Multi processing NT Fm: David Taniguchi [MS] 72350,2054 To: Jeff Nuccio 76547,2342 (X) Hi Anthony, I am checking into this. I'll post when I get more info. Basically, you will have to write a HAL (Hardware Abstraction Layer) for your machine. (This is definitely not included in the Developers SDK.) Thanks, Dave #: 15702 S9/CPU-x86 Specific 23-Oct-92 11:38:02 Sb: #15594-Multi processing NT Fm: Paul Sutter 70451,1500 To: Jeff Nuccio 76547,2342 (X) Anthony, Three (3) processors? Short on bus bandwidth? Paul Sutter #: 15704 S9/CPU-x86 Specific 23-Oct-92 11:52:38 Sb: DDK Fm: Frank Natoli [Discovery] 70744,3705 To: all I have just received the Windows NT October 1992 update/CD. There is still no info regarding DDK. When will it be available and what cost? #: 15722 S10/Porting from OS/2 23-Oct-92 17:15:46 Sb: New KB Articles Fm: Nancy Cluts - Microsoft 70744,20 To: ALL The following list consists of titles and unique identifiers of Win32 SDK technical articles contained in the Microsoft Knowledge Base used by Microsoft support staff. For access to the most up-to-date information, access the Microsoft Knowledge Base by typing 'go mskb' at the prompt. A feedback-only email alias has been set up to take any comments on the Microsoft Knowledge Base: 'y-kbfeed@microsoft.com' Thank you. -----------------------------------------------------------------------INF: OS/2-to-Windows Migration Information [P_W32dev] Q89058 -----------------------------------------------------------------------SDK9209: ScrollConsoleScreenBuffer Scrolls Foreground Buffer [P_W32dev] Q89372 -----------------------------------------------------------------------INF: Replacing the Windows NT Task Manager [P_W32dev] Q89373 -----------------------------------------------------------------------INF: Byte-Ordering in a Data Packet Under NDIS [P_W32dev] Q89374 -----------------------------------------------------------------------INF: Transparent Blts in Windows NT [P_W32dev] Q89375 -----------------------------------------------------------------------INF: How to Specify Shared and Nonshared Data in a DLL [P_W32dev] Q89817 -----------------------------------------------------------------------INF: Writing Multiple-Language Resources [P_W32dev] Q89866 -----------------------------------------------------------------------INF: Using DocumentProperties() Instead of ExtDeviceMode() [P_W32dev] Q89867 -----------------------------------------------------------------------INF: Background Information on POSIX and XPG [P_W32dev] Q89899 -----------------------------------------------------------------------INF: System Error 2: ERROR_FILE_NOT_FOUND [P_W32dev] Q89988 -----------------------------------------------------------------------INF: CreateFile() Using CONOUT$ or CONIN$ [P_W32dev] Q90088 [More] There is 1 Reply. #: 15723 S10/Porting from OS/2 23-Oct-92 17:15:51 Sb: #15722-New KB Articles Fm: Nancy Cluts - Microsoft 70744,20 To: Nancy Cluts - Microsoft 70744,20 [Continued] -----------------------------------------------------------------------SDK9210: MS-DOS-Basedand WOW Applications Won't Run on PS/2s [P_W32dev] Q90501 #: 15632 S11/Porting from Unix 22-Oct-92 14:41:21 Sb: Sun/cfront vs MS C++ 7.0 Fm: Alex Bronstein 75070,2452 To: sysop (X) My (naive) understanding is that Microsoft C++ 7.0 is based on the quasi de-facto standard in the Un*x world: cfront. Could someone from Microsoft either confirm or correct me? And if I'm wrong, does someone know the major differences? Thank you, Alex (aka internet:alex@gain.com) There is 1 Reply. #: 15660 S11/Porting from Unix 22-Oct-92 17:32:50 Sb: #15632-Sun/cfront vs MS C++ 7.0 Fm: Steve Firebaugh [MS] 75430,412 To: Alex Bronstein 75070,2452 (X) Alex, I forwarded your question to one of the people who works on the C/C++ 7.0 compiler. His response follows. I hope that it is helpful to you. -Steve Firebaugh "C 7.00 is not 'based' on cfront. No code was derived from cfront. Microsoft C++ is a native C++ compiler, not a "translator". Microsoft C++ follows the draft ANSI C++ standard. It fully implements the language as of cfront version 2.1. At this time, it does not implement cfront 3.0. What's missing is basically nested classes, templates, and exception handling. We're working on these. Microsoft is committed to implementing ANSI-standard C++." #: 15336 S12/API-RPC/WinNet 18-Oct-92 22:16:29 Sb: Networking under WOW Fm: Ravi Pandya 71461,404 To: Microsoft What sorts of network services are available to programs running under WOW? I have a network client application which I am developing under Windows 3.1, and would like to run it under NT. Are any of the following APIs available to WOW programs? - Windows Sockets - NetBIOS - Named Pipes - Mailslots Thanks! --ravi There is 1 Reply. #: 15460 S12/API-RPC/WinNet 20-Oct-92 12:10:23 Sb: #15336-Networking under WOW Fm: Lee Hart [Microsoft] 76150,2536 To: Ravi Pandya 71461,404 >>>What sorts of network services are available to programs running under WOW? I have a network client application which I am developing under Windows 3.1, and would like to run it under NT. Are any of the following APIs available to WOW programs? The general plan is to support everything that is supported under Windows 3.1. >>>- Windows Sockets Not in the October release, planned for final release. >>>- NetBIOS >>>- Named Pipes These are available in the October release (And I believe they were in the July release as well, although maybe not fully stable) >>>- Mailslots I am not sure about this, primarily because I am not familiar with mailslots under Win16. I am looking into this (it should be there, I just want to verify) Lee Microsoft Developer Support #: 15371 S12/API-RPC/WinNet 19-Oct-92 11:42:53 Sb: Net protocols and NT Fm: gary liming 71760,3221 To: ALL I have the challenge to port a protocol stack to NT. I am assuming that NT provides an Ethernet adapter interface, and I need to write some kind of loadable module with some kind of standard API interface. Question 1: How does the Ethernet interface relate to NDIS on DOS? Question 2: Is the API interface I need to provide WINSOCK or what? Question 3: Does the WIN32 SDK provide everything I need for this port, or do I need to order something else? Question 4: Do you have any advice about the best way to go about it (in general terms)? I would appreciate any advice you may have on this matter. Thanks, There are 2 Replies. #: 15406 S12/API-RPC/WinNet 19-Oct-92 18:06:20 Sb: #15371-Net protocols and NT Fm: Bruce Ramsey/Microsoft 70324,2742 To: gary liming 71760,3221 Hi Gary - >> I have the challenge to port a protocol stack to NT. I am assuming that NT provides an Ethernet adapter interface, and I need to write some kind of loadable module with some kind of standard API interface. For a protocol stack, you'll be writing a device driver for Windows NT that has an upper interface of TDI and a lower interface of NDIS 3.0 TDI (Transport Driver Interface) is the interface all protocol stacks for Windows NT must provide as their upper interface To be more precise, there are two kinds of protocol stack drivers for Windows NT: STREAMS, and all others. STREAMS protocol stack drivers will have as their upper interface part of the STREAMS wrapper. I'm not sure of the term used to refer to the upper interface a STREAMS protocol stack is written to, but it is a mapping layer between TDI and the upper interface of the STREAMS protocol stack As their lower interface, STREAMS protocol stack drivers have S-NDIS, which maps the lower interfaces of STREAMS protocol stack drivers down to NDIS Non-STREAMS protocol stack drivers write straight up to TDI, and straight down to NDIS 3.0 Examples of STREAMS protocol stack drivers would be TCP/IP or DECnet. An example of a non-STREAMS protocol stack driver would be NETBEUI >> How does the Ethernet interface relate to NDIS on DOS? Windows NT uses a later revision of the NDIS spec, NDIS 3.0 Device drivers for network adapter cards for MS-DOS or for OS/2 1.x that work with LAN Manager 2.x will need to be rewritten to the NDIS 3.0 spec (and rewritten in C to get portability to Alpha, MIPs) When you say Ethernet adapter interface, I'm assumming you mean NDIS 3.0, but please correct me if I misunderstood Note that protocol stack drivers for Windows NT will also be written in C for portability >> Is the API interface I need to provide WINSOCK or what? TDI is the interface that WINSOCK talks down to. That is, your protocol stack driver is responsible for providing TDI to WINSOCK, and to any other components at the WINSOCK level that [More] There is 1 Reply. #: 15407 S12/API-RPC/WinNet 19-Oct-92 18:06:35 Sb: #15406-Net protocols and NT Fm: Bruce Ramsey/Microsoft 70324,2742 To: Bruce Ramsey/Microsoft 70324,2742 (X) [Continued] are TDI users (such as the redirector, the server, and the NetBIOS driver). All protocol stacks for Windows NT provide TDI as their upper interface, except STREAMS drivers as noted above Device drivers for network adapter cards for Windows NT are written to NDIS 3.0, which provides both an upper and lower interface for the driver, as well as other facilities the driver needs. All of these facilities considered together are called the NDIS 3.0 wrapper STREAMS protocol stack drivers also exist within a wrapper environment that the STREAMS wrapper provides. STREAMS protocol stack drivers write up to the upper interface provided by the STREAMS wrapper, and write down to the lower interface the STREAMS wrapper provides. The STREAMS wrapper shields the STREAMS protocol stack driver from writing directly up to TDI and directly down to NDIS >> Does the WIN32 SDK provide everything I need for this port, or do I need to order something else? Since you'll be writing a device driver, you'll need the device driver kit. The people in section 13 will have more details on this kit's availability >> Do you have any advice about the best way to go about it (in general terms)? I would appreciate any advice you may have on this matter... Look at one of the sample device drivers for a network adapter, start with a copy of its sources, and add/modify code from there. Needless to say you'll need to have tools to sniff/trace the data on the test network where you're testing your protocol stack (or NDIS 3.0) driver Section 13 of MSWIN32 is the section dedicated to device driver development of all types, so you'll be asking your questions as you go in sec 13 Could you please ask now in sec 13 about availability of support for protocol stack development in the upcoming version of the device driver kit? I believe the support for doing a STREAMS driver won't be there in the version coming out in the next few weeks, but the people in sec 13 would know better than I on [More] There are 2 Replies. #: 15408 S12/API-RPC/WinNet 19-Oct-92 18:06:41 Sb: #15407-Net protocols and NT Fm: Bruce Ramsey/Microsoft 70324,2742 To: Bruce Ramsey/Microsoft 70324,2742 (X) [Continued] this, as well as on other questions in the areas of protocol stack driver development, and development of NDIS 3.0 device drivers for network adapter cards In case it might also help, I'll close by mentioning that Microsoft is offering the first-ever 32-bit device driver Developer's Conference in Anaheim, Calif., Oct. 26-28, 1992 Developers can register for the conference by calling 800/MS-SHOWS or faxing 800/936-7329 (attention department 747). Each conference participant will receive a copy of the Windows NT Preliminary DDK. For international registration, call 206/635-6435. The registration cost is $845. For developers who attended the Win32 Developer's Conference in July the registration cost is $795 Bruce #: 15412 S12/API-RPC/WinNet 19-Oct-92 19:46:58 Sb: #15407-Net protocols and NT Fm: Sheldon Fox 70162,3422 To: Bruce Ramsey/Microsoft 70324,2742 (X) Bruce, You and other MSer's keep telling us to check out Lib/Section 13. This has been closed to the general public for some time and, even tho I've seen statements that it "should" be opened up, I just tried it again right now and get the "You are not authorized to access that section" message from CI$. Did I forget to pay one of my Microsoft bills. Thanks/Sheldon There is 1 Reply. #: 15462 S12/API-RPC/WinNet 20-Oct-92 12:12:38 Sb: #15412-Net protocols and NT Fm: Bruce Ramsey/Microsoft 70324,2742 To: Sheldon Fox 70162,3422 Hi Sheldon (and others) - A thousand apologies! Yes, section 13 is still closed except to a few people that have early copies of the DDK. It should open late this month around the time of the DDK conference. Again, I apologize for my error and that of my co-workers Bruce #: 15446 S12/API-RPC/WinNet 20-Oct-92 08:57:48 Sb: #15371-Net protocols and NT Fm: Todd Needham [Microsoft] 73650,240 To: gary liming 71760,3221 Gary, Send me your mailing address and I'll get the NDIS and transport interface specifications sent out to you. Todd Needham >internet:toddn@microsoft.com #: 15331 S12/API-RPC/WinNet 18-Oct-92 09:45:33 Sb: RPC Fm: Guy Eddon 71172,1014 To: BRUCE RAMSEY To: Bruce Ramsey From: Guy Eddon CIS 71172,1014 Subject: RPC Date: 10/18/92 Thanks for your help. Here is an update on where I stand. I am able to use the 'NET SHARE' and 'NET USE' commands to share a hard drive between two computers running Windows NT. I have also been able to run the HELLO program successfully on two diffrent computers so long as both are running Windows NT. In your message you said that I need to have Microsoft LAN Manager 2.1 or 2.1a to use RPC from a DOS computer. However, the Windows NT prerelease, comes with a version of LAN Manager licensed for 10 users. Therefore, it is my understanding that all I need is a client kit to login to the LAN Manager server which is the Windows NT computer. Is there any way I can purchase a client kit for LAN Manager without buying the entire package, and don't you think it would have been nice if the drivers necessary to login from DOS were included on the prerelease CD-ROM? Aside from RPC, I would like to know if there is any way to switch the Single Command Shell to 25 line mode when I make it a full screen window. Thanks, Guy. There is 1 Reply. #: 15392 S12/API-RPC/WinNet 19-Oct-92 16:03:37 Sb: #15331-RPC Fm: Bruce Ramsey/Microsoft 70324,2742 To: Guy Eddon 71172,1014 (X) Hi Guy - >> ...Here is an update... I am able to... I have also been able to run the HELLO program... I'm glad to hear of the progress :) >> In your message you said that I need to have Microsoft LAN Manager 2.1 or 2.1a to use RPC from a DOS computer. However, the Windows NT prerelease, comes with a version of LAN Manager licensed for 10 users If you could please point me to where the July docs (or other materials) say this, I'd really appreciate it, as this would be an error we should fix in the docs or other materials. Windows NT is licensed to run on a single machine Microsoft LAN Manager 2.0 and 2.1 servers used to be licensed to allow 10 client machines to attach, and then additional user packs could be used to increase the number of users a server could support With Windows NT and the recently announced LAN manager 2.2, servers support as many licensed client machines as you have licensed on your network >> Therefore, it is my understanding that all I need is a client kit to login to the LAN Manager server which is the Windows NT computer Prior to LAN Manager 2.2, we'd never made LAN Manager client software available separately from a package that also included the server software. With 2.2 we're changing that. Here's part of the 2.2 press release ...With LAN Manager 2.2, Microsoft has changed the pricing and packaging to make it easier and more cost-effective for customers to get exactly and only what they need. LAN Manager prices will be for servers only, with no desktop (client) licenses. Customers can license desktops separately by acquiring Windows for Workgroups, which includes the client software for LAN Manager. Microsoft will offer LAN Manager 2.2 client software, based on previous LAN Manager clients, for desktops running the MS-DOS, Windows, OS/2 1.3 or 2.0 operating systems. The cost per workstation for this client software is $65. ... >> Is there any way I can purchase a client kit for LAN Manager without buying the entire package... [More] There is 1 Reply. #: 15393 S12/API-RPC/WinNet 19-Oct-92 16:03:44 Sb: #15392-RPC Fm: Bruce Ramsey/Microsoft 70324,2742 To: Bruce Ramsey/Microsoft 70324,2742 (X) [Continued] I don't believe it's posible to do so today, however in the next few days or week or two, you should be able to call 800-227-4679 and order the forthcoming Windows for Workgroups. At that number they should soon have more information on the availability dates for LAN Manager 2.2 which will have the clients for MS-DOS and OS/2 available separately >> ...and don't you think it would have been nice if the drivers necessary to login from DOS were included on the prerelease CD-ROM? Yes I do. As mentioned above, we're now changing things so that this will be easier in the future. I do apologize for the inconvenience of the past/present structure >> Aside from RPC, I would like to know if there is any way to switch the Single Command Shell to 25 line mode when I make it a full screen window. mode 80,25 works for me in the October release that you should receive in the next week or two Bruce #: 15504 S12/API-RPC/WinNet 21-Oct-92 03:39:42 Sb: #15393-RPC Fm: Jonathan Honeyball 100031,2732 To: Bruce Ramsey/Microsoft 70324,2742 (X) Hi Bruce! Presumeably the beta has now gone to production, and you're now running on something post-beta? Do you do a weekly build or something like that? Jon There is 1 Reply. #: 15520 S12/API-RPC/WinNet 21-Oct-92 10:54:28 Sb: #15504-RPC Fm: Bruce Ramsey/Microsoft 70324,2742 To: Jonathan Honeyball 100031,2732 (X) Hi Jon - >> Presumeably the beta has now gone to production, and you're now running on something post-beta? Do you do a weekly build or something like that? The beta is in production, however we aren't able to predict at this point for customers just how many days it will take for each particular customer to receive their update Like any development team, the developers constantly rebuild their part of the system as they develop new code or make corrections. It's more of an on-going thing than a weekly thing Although development and test work more with the most recent builds, those of us who work with customers a lot still use the July build so we can see what customers are seeing. So, when customers get the October build we'll all be on that, with some of us picking up later internal builds to see what problems customers report have already been taken care of Bruce #: 15509 S12/API-RPC/WinNet 21-Oct-92 08:54:43 Sb: RPC Fm: Koby 71172,2722 To: sysop (X) Hi We are porting a distributed realtime system to WinNT and plan to use the built-in RPC (current version 1.0a) as the main communucation tool. 1. Apparently there is a mismatch between the on-line documentation and the implementation of RpcMgmtIsServerListening() function. When the server does not listen, the function returns RPC_S_SERVER_NOT_LISTENING (code 1738( rather then RPC_S_NOT_LISTENING (code 1715). 2. I wrote a prototype with two processes and bi-directional RPC connection (the reversed connection is to avoid the use of the callback mechanism). Let A, B denote the to processes and A.foo and B.bar two remote function exported by A and B respectively. I tried recursive call sequence in which A.foo calls B.bar which calls A.foo ... The sequence seems to hang up after a single call in each direction. The relevant server initialization function calls are as follows: RpcServerUseProtseqEp(pszProtocolSequence, /* called from 'main' */ 100, // maximum concurrent calls Ser_pszEndpoint, 0); ..... RpcServerRegisterIf(c2s_ServerIfHandle, 0, 0); /* called from 'main' */ ..... RpcServerListen(30, 12345); /* called from a child thread */ Is this is the way RPC should behave ? If not, any idea what causes the problem ? Thanks in advance, Jacob "Koby" Avital #: 15598 S12/API-RPC/WinNet 22-Oct-92 09:07:22 Sb: #15231-TTY to TELNET Fm: Howard Myers 76711,462 To: David Taniguchi [MS] 72350,2054 (X) David, I've been waiting to see you TELNET enabled TTY program (TTY32.ZIP). This has not yet been posted and from your message I was expecting long before now. Is there a problem? Should we see it soon? Thanks! #: 15537 S12/API-RPC/WinNet 21-Oct-92 13:29:58 Sb: RPC error code Fm: Koby 71172,2722 To: sysop (X) Hi sysop We have two Win/NT systems, both with TCP/IP installed and running (can ping to each other or ftp into a Sun/OS), and are updated to RPC 1.0a (comparison of \winnt\system with 'comp' command passes with no complains). When we run the 'hellos' from \mstools\samples\rpc\hello with no parameters (i.e. it uses named pipes as transport layer), every thing is fine. However, when we run it with the following parameters hellos.exe -p ncacn_ip_tcp -e 300 It runs ok on one system but fails to create the end point on the other (error code 1720 decimal, 6b8 hex). Any idea what can cause such a problem (setup, registry, black magic, .. ) ? Thanks for your help, koby There is 1 Reply. #: 15612 S12/API-RPC/WinNet 22-Oct-92 12:31:43 Sb: #15537-RPC error code Fm: David Taniguchi [MS] 72350,2054 To: Koby 71172,2722 (X) Hi Koby, I wasn't able to get TCP working on the July Release either. Later builds work fine (NT to NT). Make sure you have both the server and client listed in the hosts file (\\system\drivers\etc\hosts) Even if you specify an IP address (ie 1.2.3.4) it appears to do a getXbyY database call. Hope this helps, Dave #: 15680 S12/API-RPC/WinNet 23-Oct-92 08:20:30 Sb: RPC error status Fm: Christian Betrisey 76600,1450 To: Microsoft When I use the RPC call RpcServerUseAllProtseqs (), I got a returned error status 0x6b7. I could find where these error status are defined. Nick Gao There is 1 Reply. #: 15696 S12/API-RPC/WinNet 23-Oct-92 11:08:03 Sb: #15680-RPC error status Fm: David Taniguchi [MS] 72350,2054 To: Christian Betrisey 76600,1450 (X) Hi Nick, >When I use the RPC call RpcServerUseAllProtseqs (), I got a returned error >status 0x6b7. Here's what the error means: MessageId: RPC_S_NO_PROTSEQS MessageText: There are no protocol sequences. >I could find where these error status are defined. Look in \mstools\h\winerror.h Note, all the error codes are in decimal -- you will have to convert any hex return codes to decimal (or print out the error codes in decimal) Hope this helps, Dave #: 15719 S12/API-RPC/WinNet 23-Oct-92 15:30:45 Sb: RPC nesting alls Fm: Koby 71172,2722 To: sysop (X) Hi I need some help. We are porting a distributed realtime system to WinNT and plan to use the built-in RPC (current version 1.0a) as the main communucation tool. 1. Apparently there is a mismatch between the on-line documentation and the implementation of RpcMgmtIsServerListening() function. When the server does not listen, the function returns RPC_S_SERVER_NOT_LISTENING (code 1738( rather then RPC_S_NOT_LISTENING (code 1715). 2. I wrote a prototype with two processes and bi-directional RPC connection (the reversed connection is to avoid the use of the callback mechanism). Let A, B denote the to processes and A.foo and B.bar two remote function exported by A and B respectively. I tried recursive call sequence in which A.foo calls B.bar which calls A.foo ... The sequence seems to hang up after a single call in each direction. The relevant server initialization function calls are as follows: RpcServerUseProtseqEp(pszProtocolSequence, /* called from 'main' */ 100, // maximum concurrent calls Ser_pszEndpoint, 0); ..... RpcServerRegisterIf(c2s_ServerIfHandle, 0, 0); /* called from 'main'*/ ..... RpcServerListen(30, 12345); /* called from a child thread */ Is this is the way RPC should behave ? If not, any idea what causes the problem ? Thanks in advance,Koby #: 15527 S14/Win32S Specific Q/A 21-Oct-92 12:41:43 Sb: Build problems? Fm: Ralph Ryan 76702,1544 To: support I ma trying to port my application, but can't get it to run once built. It compiles and links with no warnings or errors ... 1 main program and 1 DLL. THe main is linked with the .lib and .exp outputs of the DEF file. The DLL is linked with the .exp. When I run it under windbg, it gets an exception. The module load window shows USERRTL.DLL as the last thing loaded. The instruction disassembly shows: push ebp push evp, esp mov ebp, esp sub esp, 000000a8 push ebx <===== exception occurs Is this a stack overrun? Registers: cs=1b ds=32 es=23 esp=00032ffc Calltree is: _WriteConsoleInternal WriteConsoleA WriteFile _NMSG_WRITE _FFMSGBANNER _mtinit ... etc. There is a loop in the call tree, about 5 times _mtinit LdrShutdownProcess ExitProcess _c_exit _exit _amsg_exit _mtinit Development is on a 50MHz Gateway 2000 with 16Meg of memory. I can be reached (local Seattle number) at 525-2618. Thanks Ralph Ryan #: 15525 S15/Unicode/NLS 21-Oct-92 12:31:42 Sb: #15287-NT Japanese Fm: Steve Firebaugh [MS] 75430,412 To: werner krag 73127,2643 (X) Werner. The latest word that I have is that there will be a preliminary (pre-beta) release of NT-J in the next two months. I am trying to track down availability information, i.e. how you can get a copy. I'll post here when I know the answer. There is no new information on the Japanese input method editor at this point. Apparently the code for that will NOT be complete for this first pre-release. Steve Firebaugh There is 1 Reply. #: 15604 S15/Unicode/NLS 22-Oct-92 11:14:46 Sb: #15525-NT Japanese Fm: werner krag 73127,2643 To: Steve Firebaugh [MS] 75430,412 (X) Steve, thanks for the info an NT-J. As soon as you have information on WHEN the pre-beta will be ready, please post it here as many are waiting for this important NT version. Werner #: 15324 S15/Unicode/NLS 18-Oct-92 03:02:44 Sb: #15313-Complete unicode font? Fm: werner krag 73127,2643 To: Sheldon Fox 70162,3422 (X) Sheldon, I wholeheartedly agree totally what you've said about "local NT versions". The decision of Microsoft to sell local NT versions only in the target country will only make it difficult for the multilingual users (and there are many) to get the version they need. It is an outdated condescending attitutde on the side of Microsoft. I definitely hope local versions of NT will be available to anyone who wants them anywhere. As a minimum requirement I would suggest that Microsoft USA will sell any version. Werner #: 15326 S15/Unicode/NLS 18-Oct-92 04:07:10 Sb: #15270-Complete unicode font? Fm: Neil Robinson 100016,2775 To: Steve Firebaugh [MS] 75430,412 (X) Answer me a really dumb question then: Why bother with UNICODE at all? The whole point is that the people who *want* Unicode need to be able to access several different languages and input methods on the same OS and in the same document. There are a large number of users out there who need to be able to combine Japanese and English and Arabic in the same document. It is totally ludicrous to go to all of the trouble to implement Unicode and then tell those users that they will not be able to use those characters on their systems. That was the whole point! I also don't want to buy a Japanese Windows or a Chinese Windows or even an Arabic Windows just to type charaters in those languages. That should be possible regardless of the current language of the OS. I may need some way of switching input methods on the fly, but that should be the only hinderance to using Unicode characters. I myself speak, read and write English, German, and Japanese, and am learning Hindi and Tibetan. Now you are telling me that I can't write letters or theses or whatever in those languages, even though they are supported by NT, unless I buy a version of NT for each? And even then I won't be able to mix the characters in one document? I might as well buy a MAC! They can *currently* do this. Ciao, Neil #: 15335 S15/Unicode/NLS 18-Oct-92 17:29:39 Sb: #15270-Complete unicode font? Fm: Sheldon Fox 70162,3422 To: Steve Firebaugh [MS] 75430,412 (X) Steve, The more I think about your response saying National Language versions will only be available in their respective countries, the more upset I get (I know--I should just stop thinking about it then! ). MS has made a major step forward by making NT fully Unicode internally. This goes a long ways towards solving many of the problems with making applications work in a world-wide market. PLEASE don't take 9/10ths of a step back by restricting sales of Nationalized versions of NT to specific countries! To ALL: Let's apply some "Compuserve pressure". All of you who are developing apps for the international market and think that the position of the MS "program manager for International Windows/NT" with respect to this issue is a BIG mistake, please append a message to this thread so that Steve can take the responses back to him/her and see if this type of attitude can't be changed before the actual product release. Thanks/Sheldon There is 1 Reply. #: 15439 S15/Unicode/NLS 20-Oct-92 06:29:15 Sb: #15335-Complete unicode font? Fm: David Van Camp 70740,366 To: Sheldon Fox 70162,3422 <> Hear, Hear!! I totally agree! The ability to work with multiple languages simultainously is a *MAJOR* feature advantage of Unicode. No allowing this in an upcomming release of NT will simply push users with multi-lingual requirements to the Mac. PLEASE CHANGE YOUR POSITION ON THIS, MS!! thank you, dvc There is 1 Reply. #: 15483 S15/Unicode/NLS 20-Oct-92 14:38:40 Sb: #15439-Complete unicode font? Fm: Kent Olsen 72360,3035 To: David Van Camp 70740,366 Our company has looked toward Unicode as an answer to several problems we face as we try to roll-out systems to sites around the world. It is unfortunate that MS is making it harder to do so by forcing us to work with many different versions of NT. We would also like to see Unicode capability built into the Windows/DOS platform. - Kent #: 15360 S15/Unicode/NLS 19-Oct-92 09:53:17 Sb: #15270-Complete unicode font? Fm: Steven Olson 70313,2246 To: Steve Firebaugh [MS] 75430,412 (X) Steve, I too believe it is a mistake not to include full access to all the unicode fonts. Individual developers may have to implement such features as right to left ordering or bottom to top, but at least let us have access to the fonts! As previously mentioned, why are you even bothering with unicode if you are going to localize every version? Unicode is supposed to simplify the problem of combining Chinese, Japanese, German, etc... in a _single_ document. Please don't lead us into the Dark Ages. (Remember the Rosetta stone....its value was having three different languages on one tablet, not having three different "localized" tablets.) While I also realize you are unlucky enough to have your name attached to this thread, PLEASE pass on all of our concerns to the "proper" authorities. Thanks! Steven Olson Canon Research Center, America #: 15411 S15/Unicode/NLS 19-Oct-92 18:57:12 Sb: Complete unicode font? Fm: Steve Firebaugh [MS] 75430,412 To: All First of all, thank you all for your input on this issue. It is being discussed right now at Microsoft. I hope to have some more information for you in the next few days. However, for now I would like to make the following points: 1. Localization is a valid practice. A customer in Greece should be able to buy a Microsoft product with instructions and message strings written in Greek. If done correctly, it is a service to the people of the targetted country, not a hinderance. 2. I personally agree that a font covering all codepoints should be available to any international customer. I am certain that if Microsoft does not satisfy this need, then some other company will. Nevertheless, I will continue to argue the point within Microsoft that Microsoft should be doing it. 3. There is a difference between localized input methods, and international input methods. In order to appeal to the established customer base within a country, it is necessary to provide support for existing (localized) methods which people have become accustomed to. It is not true that the ideal international workstation would simply provide access to all of the existing input methods. That would place confusing, inconsistent demands upon both the user and upon the hardware. A true international input method has yet to evolve. I have seen some attempts on the Macintosh, we should expect to see an expanded CHARMAP accessory (not yet in the October beta though), and I will upload a simple application next week that allows the user to pick any character currently covered by a font. 4. Despite the distribution of localized versions of Windows/NT there are many advantages to having built the system upon unicode. Developing international applications is easier, the codepage confusion will be cleared up, transmitting documents internationally will be simplified, the October beta already has coverage of approximately 1100 codepoints, the fact that Windows/NT is unicode conformant will make its integration into international systems easier, etc. Steve Firebaugh #: 15501 S15/Unicode/NLS 20-Oct-92 21:19:43 Sb: #15411-Complete unicode font? Fm: Paul Watson [XLsoft] 76056,1751 To: Steve Firebaugh [MS] 75430,412 (X) Please make the base system standard across all localizations. Any customer should be able to add any front end input method. The entire product line should be available worldwide and orderable through any point which Microsoft distributes any NT product. Are you really saying it is a technical issue. Yes, there are lots of problems in developing a design that will allow multiple language input. You are very close to an elegant solution. Don't give up the battle yet. It is worth the fight. If it is like most international products, the real issues are accounting and support. The bean counters don't know what to do with themselves if someone in France wants to buy a Thai font. Please see youself past this and develop a truly world class global corporation. Support is a tough one. It is reasonable to expect that support for a Japanese IME be in Japanese. Providing developer support in the national language and English would help ISV and IHV developers to produce more and higher quality product for NT. The FESDK is a good example. #: 15581 S15/Unicode/NLS 21-Oct-92 23:49:45 Sb: #15411-Complete unicode font? Fm: Jon Babcock 72076,567 To: Steve Firebaugh [MS] 75430,412 (X) Steve, Appreciated receiving your response and the reaction to your response from others to my question about the availability of a complete unicode font. Microsoft's statement confirmed our worst suspicions and, quite frankly, it has taken a few days to get over our initial disappointment, apparently shared by Sheldon Fox, Werner Krag, Neil Robinson, and others. We understand that there are advantages in using unicode FOR MICROSOFT. But it is disheartening to hear that the promise of unicode will not be realized in WinNT for the user who wants to incorporate several of the languages covered by the code within one document. Again, MS forces us to buy specifically JAPANESE hardware from the likes of NEC, Fujitsu, Epson, and others to run the product. This is not the case with Chinese or Korean, of course. I'm not saying that Microsoft should not produce localized OEM-specific software. But I am extremely curious to know why, without any serious technical obstacle, it has chosen to exclude only Japanese software from IBM PC compatibles. Why are we and Japanese users restricted BY MICROSOFT to buying equipment from Japanese manufactures if we want to run Microsoft Japanese products? Note that it is precisely the Japanese Windows 3.0A in the FESDK that is not complete because no IME is included. We have it for Chinese and Korean, but not for Japanese. (In fact, to input Japanese into anything in the FESDK JWIN requires the purchase of an additional product, the Kana- Kanji converter, a $249 item from the only U.S.-based source mentioned in the SDK.) [continued in reply] There is 1 Reply. #: 15582 S15/Unicode/NLS 21-Oct-92 23:50:37 Sb: #15581-Complete unicode font? Fm: Jon Babcock 72076,567 To: Jon Babcock 72076,567 (X) [continued] Note that Microsoft has not enhanced Chinese Windows by including the approximately 1000 additional characters needed to input Japanese or even the approximately 100 needed for katakana and hiragana? These are all included in ET, an alternate Chinese system available in Taiwan, for example, and there is plenty of room for them in user- definable areas of the BIG5 code. The supplied IME for accessing these could be as minimal as allowing the user to input the BIG5 code, leaving complete IMEs for independent developers. Don't forget, in Chinese windows the user can install and then switch from one IME to another easily. I mention these points to show that it is not a technical problem that prevents using Japanese on "standard" IBM PCs, but that it seems to represent a pattern of POLICY, of special policy in the case of Japan. Could this have something to do with why Microsoft is not providing a full unicode implementation on WinNT? If Microsoft, to protect its share of the market in Japan, has an agreement with the big Japanese companies not to release software that can effectively use Japanese language running on IBM PC compatibles (such compatibles from the U.S., Hong Kong or Taiwan have been often less than half the price of equivalent Japanese hardware, and even the recent price reductions in Japanese machines are probably partly due to pressure from such things as IBM's DOS/V that DOES run on our PC compatibles), then Microsoft's business decision not to provide U.S. PC users access to a font that covers the complete unicode kanji set would be understandable. But it is not acceptable. [continued in reply] There is 1 Reply. #: 15583 S15/Unicode/NLS 21-Oct-92 23:51:08 Sb: #15582-Complete unicode font? Fm: Jon Babcock 72076,567 To: Jon Babcock 72076,567 (X) [continued] Re your second response: As mentioned above, we have no quarrel whatsoever with Microsoft's intention to produce different versions of its products for different countries. If the menus, dialogs, documentation, etc. is in the local language, great. Our point is that no matter which country's version of the software we are using, we should be able to produce DOCUMENTS that contain all the unicode languages. This involves having access to a font that contains all the characters, and a choice of IMEs. Following up on what Sheldon Fox said, the supplied complete font doesn't need to be fancy and there need be only one complete font. But even before such a complete unicode font is available could not Microsoft make available a preliminary version to developers? It could be one size etc. We want to proceed quickly in developing software that can display various language sub-sets of unicode. Is this asking too much? In the case of kanji, at least, Microsoft already owns some fonts, as seen in JWIN, CWIN, and KWIN. Re your third point that the ideal criterion for an international workstation is not simply to provide access to all of the existing input methods: Please remember, with NT as it is now, we are stuck with NO ability to input multilingual text into a document, period. Until an ideal unified input system is invented, a way to install multiple IMEs under WinNT would result in the next best thing. Furthermore, we don't expect Microsoft to provide an IME for every language in world. We want the IMEs to be available (whether from Microsoft or others), installable, and switchable. For example, when NT/J is finished, we want to be able to buy the IME that Microsoft licensed and install it in our U.S. WinNT. Again, we appreciate the fact that you are keeping the lines of communication open. Thank you, Jon #: 15622 S15/Unicode/NLS 22-Oct-92 13:55:33 Sb: #15411-Complete unicode font? Fm: Andrew Potter 71075,614 To: Steve Firebaugh [MS] 75430,412 (X) Steve, Earlier you said: > The Japanese product will have TT Kanji fonts, JIS level II at > a minimum. The Chinese product TT font will be BIG-5 coverage at a > minimum. Both will be Unicode encoded." Let me assume that every character in the TT kanji fonts, JIS level II and BIG5 is in the UNICODE font. Do you provide a converter to convert the existing code-set font to the UNICODE encoded font? Is the converter built in the NT? Thanks, Andrew There is 1 Reply. #: 15725 S15/Unicode/NLS 23-Oct-92 17:17:40 Sb: #15622-Complete unicode font? Fm: Steve Firebaugh [MS] 75430,412 To: Andrew Potter 71075,614 Andrew, >Let me assume that every character in the TT kanji fonts, JIS >level II and BIG5 is in the UNICODE font. Do you provide a converter >to convert the existing code-set font to the UNICODE encoded font? >Is the converter built in the NT? Depending on the definition of the existing True Type font that you have, no such conversion may be necessary. There are optional tables in the True Type header, and the fonts you have may already have the table needed to be displayed for a unicode string. I do not believe that there will be a conversion tool to 'fix' arbitrary fonts without this table, such that they'll be useable with unicode. However, if the font is currently working with Japanese Windows or Chinese Windows, then the design intent of the proper localized Windows/NT will be that the font will continue to work. Steve Firebaugh #: 15685 S15/Unicode/NLS 23-Oct-92 09:55:23 Sb: #15411-Complete unicode font? Fm: Tim Hyde-Smith 100023,3320 To: Steve Firebaugh [MS] 75430,412 (X) Let me add my voice to the clamour against the notion of localisation as outlined in previous postings on this thread. I too work for a company producing heavily text-based applications with clients all over the world. In the past we developed a proprietary method of allowing them to include native-language characters in documents they produced on our system; accordingly we have installations in Scandinavia, Germany, France, Benelux, Hungary, Singapore, India, Thailand, etc. etc.. Much of our technical support work is done from London. We have been looking at ways to reconcile our scheme with that of Unicode so as to enjoy the internationalising benefits of Unicode and NT. It would seem, however, that there's no advantage in that since in order to carry on our support work, we would need a separate NT installation for each locale in which we have a client. This seems _very_ unnecessarily expensive. - Daryl, masquerading as Tim with his knowledge and consent :-> #: 15530 S15/Unicode/NLS 21-Oct-92 12:59:38 Sb: #15270-Complete unicode font? Fm: Sheldon Fox 70162,3422 To: Steve Firebaugh [MS] 75430,412 (X) Steve, >First of all, thank you all for your input on this issue. It is being >discussed right now at Microsoft. I hope to have some more information for you >in the next few days. However, for now I would like to make the following >points: > > 1. Localization is a valid practice. A customer in Greece should be able to >buy a Microsoft product with instructions and message strings written in Greek. >If done correctly, it is a service to the people of the targetted country, not >a hinderance. > > 2. I personally agree that a font covering all codepoints should be available >to any international customer. I am certain that if Microsoft does not satisfy >this need, then some other company will. Nevertheless, I will continue to >argue the point within Microsoft that Microsoft should be doing it. > > 3. There is a difference between localized input methods, and international >input methods. In order to appeal to the established customer base within a >country, it is necessary to provide support for existing (localized) methods >which people have become accustomed to. It is not true that the ideal >international workstation would simply provide access to all of the existing >input methods. That would place confusing, inconsistent demands upon both the >user and upon the hardware. A true international input method has yet to >evolve. I have seen some attempts on the Macintosh, we should expect to see an >expanded CHARMAP accessory (not yet in the October beta though), and I will >upload a simple application next week that allows the user to pick any >character currently covered by a font. > > 4. Despite the distribution of localized versions of Windows/NT there are >many advantages to having built the system upon unicode. Developing >international applications is easier, the codepage confusion will be cleared >up, transmitting documents internationally will be simplified, the October beta [>> Continued in next msg] There is 1 Reply. #: 15531 S15/Unicode/NLS 21-Oct-92 12:59:53 Sb: #15530-Complete unicode font? Fm: Sheldon Fox 70162,3422 To: Sheldon Fox 70162,3422 (X) [>> Continued from previous msg] >already has coverage of approximately 1100 codepoints, the fact that Windows/NT >is unicode conformant will make its integration into international systems >easier, etc. > >Steve Firebaugh I think most all of us would agree with all the points you made above. Perhaps I was not clear enough in my original reply to you about what we are asking for. We are NOT saying that you shouldn't produce localized versions of NT. What we ARE saying is that these localized versions must be made available on an international basis, and not just from the Microsoft office in the country for which it was localized. It is not a valid assumption that the only customers who want a given version localized for a specific country are residing in that country and therefore can contact the Microsoft rep in that country to get a copy of the localized NT. There are MANY developers that are developing applications that are to be used in more than one country, which obviosuly implies that they need access to localized versions of NT for countries other than the one in which they live. As you mentioned, there would ideally be one "global" input method editior that could be a part of the base version of NT. Until then, it is very important that ALL localized versions of NT be made available to any developer, regardless of the country in which that developer happens to have his/her mailbox. It is also very important that the full Unicode font, when completed, be in ALL versions NT so that a document, regardless of what language is was written in, can at least be displayed (altho possibly not edited unless the proper IME is available) on ANY version of NT. It is not sufficient to have different customized versions of the Unicode font available only with the localized versions of NT. (I'm talking about the "system" Unicode font--not implying that every Unicode font in NT have all 35K code points). If you don't make at least one Unicode [>> Continued in next msg] There is 1 Reply. #: 15532 S15/Unicode/NLS 21-Oct-92 13:00:01 Sb: #15531-Complete unicode font? Fm: Sheldon Fox 70162,3422 To: Sheldon Fox 70162,3422 (X) [>> Continued from previous msg] font available with ALL characters for ALL languages, you will--as many have pointed out here--defeat the purpose of having Unicode in the first place since there won't be the ability to display any document on all systems. This is the situation we have now with Windows 3.1 and Unicode should be the mechanism used to eliminate this restriction in NT. Thanks for taking our concerns to the proper people and we look forward to your response. Sheldon There are 2 Replies. #: 15640 S15/Unicode/NLS 22-Oct-92 15:21:21 Sb: #15532-Complete unicode font? Fm: David Van Camp 70740,366 To: Sheldon Fox 70162,3422 (X) [continued from previous reply to Sheldon...] But, how about simply including all possible glyphs in our unicode font? First, at least theoretically, there is an infinite number of permutations of all possible valid unicode char code sequences which could represent a unique glyph. In reality, however, only a finite number of these are ever encountered in the languages currently represented. But this is a HUGE number. Add to this the number of characters which are represented multiple glyphs depending on the context in which they are used (deterministic contextual variants), valid individual chars which are represented by a single glyph when found in a specific sequence (ligatures), font and style variants, and directional variants, and you would require a font which is far, Far, FAR in excess of the 64K glyphs. For these reasons, when we speak of a `unicode font', we mean a font that supports the unicode character set - not one that actually has any 1-1 mapping to unicode. THERE IS - AND NEVER WILL BE - ANY SUCH THING AS A UNICODE FONT. So I can't just run CHARMAP and copy the character(s) I want to the clipboard. So much for that idea. The only solution currently available is that I use, in my application, an edit field (or whatever) to enter the unicode char code(s) of the character(s) (glyphs) that I want - after looking them up in the 2 volumn unicode standard), and have the application insert the codes into a unicode string and then display it (or copy it to the clipboard, etc.) As a matter of fact, in order to properly test my application in a few weeks, I'm going to have to do exactly this. but.... NT *NEEDS* A STANDARDIZED WAY TO ENTER ANY UNICODE CHARACTER(S). As a programmer, I can solve the problem for my program - but I can't do anything about W4W, or any other application. And this really should be the responsability of the GUI so that all applications handle it in a similar maner for the current localized environment. dvc #: 15641 S15/Unicode/NLS 22-Oct-92 15:21:28 Sb: #15532-Complete unicode font? Fm: David Van Camp 70740,366 To: Sheldon Fox 70162,3422 (X) Sheldon , I agree that including at a minimum a single font containing the entire PRINTABLE Unicode character set is a requirement - I discussed this with Microsoft's Asmus Freytag at the Unicode Implementor's Conference #2 in San Jose, and he agrees fully. (Asmus also serves as the Vice Pres. of Mktg for the Unicode consortium. Unfortunately, he does not have a CIS account - or didn't last I asked him - so you won't see him here :( However - I do not believe that this is enough. ALL localized versions of NT MUST provide SOME way of entering ALL possible unicode characters. While the required method might be cumbersome and slow, there must be a way for a user to enter text of a radically different nationality. Why? Simple: Let's say I'm a linguist and wish to produce a document, primarly written in English, in which I discuss the history of the Arabic and Hebrew languages. I certainly would want to include text examples of these languages in my (oh, let's just say..) MS Word for Windows NT document. Let's presume that we DO have a complete unicode font to use. Now, how would I do this? Let's see, I could run CHARMAP or some other font viewer, scroll through the font and find the character I want, copy it to the clipboard and then paste it into my document. Tedous, but it works - right? WRONG! Many glyphs (a single display character) in unicode are constructed from multiple unicode characters. For example, in modern Arabic, Hebrew and many other languages, vowel sounds or phonetic tones are not represented by an indiviual glyph. Instead, unicode represents them with `non-spacing marks' (accents) which are combined with one or more other characters to produce a finished glyph. And there are some fairly complicated rules about how to combine these accents with the consonant to produce a properly displayed glyph depending on the language, culture and other factors. [continued in next reply to Sheldon's message...] There is 1 Reply. #: 15726 S15/Unicode/NLS 23-Oct-92 17:17:51 Sb: #15641-Complete unicode font? Fm: Steve Firebaugh [MS] 75430,412 To: David Van Camp 70740,366 David Van Camp, >I agree that including at a minimum a single font containing the entire >PRINTABLE Unicode character set is a requirement >... >However - I do not believe that this is enough. ALL localized versions of NT >MUST provide SOME way of entering ALL possible unicode characters. While the >required method might be cumbersome and slow, there must be a way for a user >to enter text of a radically different nationality. I agree strongly with you on these two points. Unfortunately, for the state of the Windows/NT world with respect to unicode, this is all that we are arguing for in this thread. You are absolutely correct, in so far as unicode works, when you say: >... >WRONG! Many glyphs (a single display character) in unicode are constructed >from multiple unicode characters. For example, in modern Arabic, Hebrew and >many other languages, vowel sounds or phonetic tones are not represented by an >indiviual glyph. Instead, unicode represents them with `non-spacing marks' >(accents) which are combined with one or more other characters to produce a >finished glyph. And there are some fairly complicated rules about how to >combine these accents with the consonant to produce a properly displayed glyph >depending on the language, culture and other factors. However, support for the display of unicode strings, where the mapping between the codepoint and the glyph isn't approximately 1:1, will NOT be in Windows/NT product 1, nor will it be in NT/J. (The use of 'approximately' arises from the fact that the diacritical marks in the range U+0300 -> U+036f currently are supported.) The background you've provided is valuable, and I hope that you'll continue to post informational messages like this. I felt that it was important to clarify the relation between your comments and the existing system. Steve Firebaugh #: 15724 S15/Unicode/NLS 23-Oct-92 17:17:34 Sb: Complete unicode font? Fm: Steve Firebaugh [MS] 75430,412 To: All Once again, thank you everybody for the input. You have presented a strong argument which I have been paraphrasing as, "Provide a version of Windows/NT to the international market which will have international capabilities." I will continue to argue this stance with the people making related decisions at Microsoft. At this point, I would like to attempt to make a clarification regarding the discussion in this thread. I believe there are two aspects to what people are saying. The first is primarily technical, and that is the international capabilities of Windows/NT. I.e. move as much as possible of the functionality normally left to localization into the base system which is common to all versions. Specifically, we need a font that covers all unicode codepoints, and we should have some kind of generalized input method which will allow the user to specify any unicode codepoint. The second aspect is restricted distribution. I will not deny that there may be business-driven motivations behind the nationally constrained access which many of you have experienced in the past with other Windows products. I can not say much on this, because I honestly do not know anything about it. My intuition is that if we can solve the problems listed in the paragraph above, then these restrictions will be of less consequence to programmers interested in unicode. (I do not mean to downplay the problems arising from restricted distribution... Please notice they have been discussed at some length in sections 1 and 17 of this forum... Also, please notice that the localized versions of Windows 3.x were given away 'free' (price of admission) to all attendees of the PDC conference in San Fransisco.) Thanks again for for your input. I am trying hard to see that it makes a difference. Steve Firebaugh #: 15343 S17/Unmonitored Chat 19-Oct-92 04:18:31 Sb: #15186-Friendly Comparisons Fm: Andy Champ 100064,2267 To: Paul Pignatelli 76367,2721 Paul, you misunderstand me. I work for ICL full time - and have done for 13 years, much to my surprise - and some parts of ICL are very much up to speed on NT. And OS/2! The people who did not know of NT were the people who send out the leaflets, and that's probably just because there aren't any copies being sold yet. BTW - what important paper? Andy. #: 15605 S17/Unmonitored Chat 22-Oct-92 11:36:10 Sb: Where'd everybody go? Fm: KENNETH R SCHROCK 70621,1521 To: All Traffic on this board has dropped to almost nothing. Does this mean: A. Everybody is finished with their work? B. Everybody is waiting for the beta? C. Everybody gave up and went home? D. Lot of vacations this time of year? There is 1 Reply. #: 15645 S17/Unmonitored Chat 22-Oct-92 17:17:10 Sb: #15605-Where'd everybody go? Fm: Anthony Murfet 70602,1634 To: KENNETH R SCHROCK 70621,1521 (X) Ken, Everybody is waiting for the beta Traffic has dropped in WINNT too. Tony. There is 1 Reply. #: 15681 S17/Unmonitored Chat 23-Oct-92 08:39:02 Sb: #15645-Where'd everybody go? Fm: Howard Silver 76675,3476 To: Anthony Murfet 70602,1634 (X) Agreed. I'm waiting for the BETA as well. After the NT conference I was on these forums almost everyday. Now, not so much. In fact, this is the first time I've been back here in 3 weeks. - Howard Silver There is 1 Reply. #: 15720 S17/Unmonitored Chat 23-Oct-92 15:57:43 Sb: #15681-Where'd everybody go? Fm: Anthony Murfet 70602,1634 To: Howard Silver 76675,3476 Well, having thrown every Win16 and DOS app I had at the July release I am kinda hoping that more of them will work this time around, though I am not betting too much on apps like winfax or procom for win. Tony. There is 1 Reply. #: 15721 S17/Unmonitored Chat 23-Oct-92 17:00:31 Sb: #15720-Where'd everybody go? Fm: Carl H Bache [PS Norway] 100010,2257 To: Anthony Murfet 70602,1634 Well, I'm back - WITH the beta, and boy, is it superb! You guys should be looking forward to see some impressing speed coming up... Dag Baardsen