CICA 1993 August/CICA.cdr/unzipped/nt/msg1/mswin32.msg

Text File | 1992-10-24 | 243.7 KB | 7,434 lines

#: 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. <g>

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 <grin> 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 <g>.

#: 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,

 <<After installing the primary release of Windows NT by the alternate method,
I
  mentioned two problems:

  1) My SoundBlaster Pro was whistling all the time.
     Settings: INT 10, Port 220, DMA 1

  2) At the DOS-Prompt, I always got an US-Keyboard-Driver, although
     I changed by the Online-Setup to German.

  Do You know a solution to this problems?>>

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,

<<Does anyone have an opinion on the Chinon drive available by special offer
in the WIN32 CD package?>>

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 <g>. 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 <g>??  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 <g>! Thanks
for reporting this problem - let me know where you get stuck next <g>! 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:<file>.def <file.obj> \
    -out:<file>.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,
                           <handle of target process> // Must be a "real"
handle with at least PROCESS_DUP_HANDLE priviledge.
                           &hRealHandle,
                           <desired access>, // Ignored if
DUPLICATE_SAME_ACCESS is specified below
                           <inhert handle>, // 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. <segname> is the name of your data section. #pragma
data_seg("<segname>","")

.. data
.. #pragma data_seg(".data","")    // instance data
...

Next in the DLL's def file add the following line

SECTIONS
   <segname> 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<cr>, 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.



<makefile begin> all:
   cl386 -c -Gs -W2 -nologo -Fa shift.c <makefile end>


<source begin> main () {
   unsigned  num;
   unsigned  x;


   num = 1388;

   if (((unsigned char) ((num & 0x00000F00) >> 8)) > 9)
      x = num;
   else
      x = num + 1;

} <source end>


<asm output begin>
        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 <asm output 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 <g>.

> 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: '[e-mail]'  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 <windows.h> #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.
        [phone] 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: '[e-mail]'  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:   [phone]  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: '[e-mail]'  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:[e-mail])




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. <g>

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:[e-mail]

#: 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
  (\<ntroot>\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! <g>).

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

<<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.>>

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 <actually this is directed to MS>,

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