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

Text File | 1992-10-31 | 364.7 KB | 11,079 lines

#: 15731 S1/NonTech Cust. Serv.
    24-Oct-92  01:13:52
Sb: Message Archive Avail!
Fm: Otto Fung 76260,631
To: All

Hello All,

        Messages Archive for MSWIN32 forum is now available. I will post the
archive weekly on every (roughly) Friday. It's name is MSG*.ZIP while * is the
week number since the archives started. The first one is MSG1.ZIP on library 1
- New Uploads.

        I would like to thank Steve, sysop of the WINNT forum on CompuServe,
by providing a good package to help me to process the archive. I hope that the
format of the archive file is good and acceptable. And welcome for feedback.

        Otto Fung


#: 15734 S1/NonTech Cust. Serv.
    24-Oct-92  06:49:30
Sb: #15348-compuserve support
Fm: Scott Wheeler 100022,2005
To: John Oellrich 72611,1452 (X)

Thanks for the advice. Trouble is now nothing on the PC displays *anything*
coming from the modem, despite that I can see and hear that the manual
commands let it log on. Works as normal on the Sun, and I can't think of
anything that I've changed that would survive a reset I suspect this is God's
way of telling me that Real Micros are standalone and run CP/M. I think I try
swapping a few PCs to try to find out more, though I did that earlier with no
more success.

Scott

#: 15735 S1/NonTech Cust. Serv.
    24-Oct-92  06:53:27
Sb: #15447-compuserve support
Fm: Scott Wheeler 100022,2005
To: John Mueller [DBA] 75300,576

No, it's supposedly a standard Hayes modem, although Unix machines are very
flexible in the modems they support (the obfuscation department was on holiday
when this part of the OS was designed). Sorry, meant Hayes compat.

I'd probably better stop talking on this thread before the sysop (editor?
forget word) give the heavy look. Thanks to all for your advice.

Scott

#: 15779 S1/NonTech Cust. Serv.
    26-Oct-92  09:51:17
Sb: #15728-Oct Win32SDK Docs
Fm: Stu Wiley 70473,1351
To: John Reece 70153,2077

John,  I sent you a copy.  You should get a replacement wqithin a few days.
 Stu Wiley Developer Service Team

#: 15766 S1/NonTech Cust. Serv.
    26-Oct-92  06:21:22
Sb: NT Mailslot Read
Fm: Mark A Skerencak 71214,262
To: Microsoft

I am having problems porting a unix inter process communication (IPC)
application. The unix application uses mailslots as I am attempting to do. The
test bed I am using is a single process that spawns two threads. Each thread
connects to a mailslot and continuously reads the mailslot to see if a message
have arrived.   I have set the timeout to MAILSLOT_WAIT_FOREVER. I do not want
the function ipc_msg_receive() to return until it has read a message. The code
below attempts to do that but it returns if the mailslot is empty.  Does the
call
SetMailslotInfo with a timeout of MAILSLOT_WAIT_FOREVER have any affect on the
ReadFile() call? Will the ReadFile() call return an error (fResult == 0) if
the
mailslot is empty (that is what it is doing now) even if the timeout was set
to
wait forever? Should I be using Named Pipes instead? Any help or sample
applications you could provide would be greatly appreciated.

#: 15783 S1/NonTech Cust. Serv.
    26-Oct-92  11:49:20
Sb: #15766-NT Mailslot Read
Fm: Jerry Drain [Microsoft] 72350,2056
To: Mark A Skerencak 71214,262

Hi Mark,

We've devided up the forums into sections where we can group like questions,
and so you can ask your question in a specific location where our different
expertise are assigned to monitor CIS traffic.  Your question is very
technical, and this specific section is the non-technical customer service
section.  I see that you've already posted this question in section 6
(Base/Security), which was appropriate.  You might also find information
helpful to you in the section for porting Unix (section 11), and the section
for RPC (section 12).

Thanks,
  -- Jerry [@Microsoft]

#: 15736 S1/NonTech Cust. Serv.
    24-Oct-92  06:58:23
Sb: Testing Win 3.1 Products
Fm: Leon G Rollison 70421,1702
To: David Taniguchi 72350,2054 (X)

David,

I finally got Win32 running on my system after biting the bullet and
purchasing an Adaptec 1542B SCSI Controller.

I am impressed with the stability of the product as it stands now.

I have two questions.

1)  I tried to install my Win 3.1 Trutype fonts and wound up with     huge
dialog boxes and fonts.  Why?

2)  I have a fairly large number of Win 3.1 applications.  Would     anyone as
Microsoft be interested in those product's ability
    to run under Win32?  I have already played around with Borland
    C++ 3.1.  It seems to run O.K. if I place WINSTUB.EXE in the
    MSTOOLS directory where Win32 can find it.  My applications are
    as follows:

        Microsoft Word for Windows 2.0
        Microsoft Excel 4.0
        Microsoft Project 3.0
        Microsoft SDK & C/C++ 7.0
        Borland C++ & Application Frameworks 3.1
        Borland Turbo Pascal 1.5
        Borland Objectvision 2.1
        PC Tools Backup for Windows 7.2
        Perform PRO Plus
        On Time 1.0
        Winfax Pro 2.0
        Quicken

I don't know if compatibility issues whoul be of any help to your development
team, but I would be willing to do some compatibility testing if I could be of
any help.  Please let me know.

Thanks,
Leon

There is 1 Reply.

#: 15796 S1/NonTech Cust. Serv.
    26-Oct-92  13:38:26
Sb: #15736-Testing Win 3.1 Products
Fm: Stu Wiley 70473,1351
To: Leon G Rollison 70421,1702

Leon,

Sounds like you have some good things to work with.  And thanks for the
offers. You will probably want to post your first question (size of dlgs,
fonts in WinNT) in section 5 of this forum.  The second you will probably want
to put in the WINNT section 4. I may not be totally accurate here, but they
are the best thoughts I have.

As far as compatability testing, we try to get total involvement by the
companies responsible for each respective product.  Ask the folks in the WINNT
forum section 4 for ideas and options.
 Stu Wiley Developer Service Team

#: 15870 S1/NonTech Cust. Serv.
    27-Oct-92  10:35:08
Sb: Your MSG
Fm: Robert Eidson 70214,2115
To:  70744,24 (X)

Paul:
   Your message this morning helped.  I will start to work with these tools. I
need a few pointers on some basic fundementals.  For the time being I'm going
to continue to use (when I can get it working again (g)) C 6.0 for the daily
bread'n'butter stuff.  Meantime I want to quickly move development into the NT
arena.  My questions: (1)What are the steps I need to follow to do a
compile/link in NT? (2) Is WinDbg the place I go for codeview support in the
debugging stage? (3) Is the C 7.0 I have with NT suitable for creating DOS
programs? If yes can I still use WinDbg to debug them or should I switch to
the CV supplied with C 6.0?
   Besides the foot and a half of technical manuals I received with the July
release of NT I have nothing else. I know I know, whats new (right (g)). Where
do I get helpful lit. on these basic operating procedures and practices?  I
sure don't want to pester you for all of the details.
   Thanks for everything.        Bob Eidson

#: 15863 S1/NonTech Cust. Serv.
    27-Oct-92  10:15:19
Sb: Tools et al
Fm: Robert Eidson 70214,2115
To:  70744,24 (X)

Paul: I'm having trouble getting a msg back to you. Did you receive this one?
I'm having problems with my system configuration. I have C 6.0, Windows for
Workgroup and NT.  When I now use NMAKE (and NMK) it fails.I have the
following MAKEFILE:

styedit.obj : styedit.c
    cl  /c /AS /Od /Zi styedit.c

styedit.exe : styedit.obj
   /LINK /CO styedit.obj

When I type NMAKE I get the following failure:

        cl  /c /AS /Od /Zi styedit.c styedit.c fatal error C1002: compiler is
out of heap space in Pass 2 NMAKE : fatal error U1077 : 'cl' : return code '2'
Do you have any clue as to what I've mucked up?     Bob Eidson



There is 1 Reply.

#: 15897 S1/NonTech Cust. Serv.
    27-Oct-92  15:21:41
Sb: #15863-Tools et al
Fm: Jerry Drain [Microsoft] 72350,2056
To: Robert Eidson 70214,2115 (X)

Hi Bob,

PMJI, but if you have many questions on these subjects, you can answer them in
the tools section (MSWIN32/Section 7).  A good starting point is to look at
the SDK samples provided in \mstools\samples\ .  There is also a Q_A\samples
directory included with the SDK that has additional samples, and a collection
of KB articles.

Thanks,
  -- Jerry [@Microsoft]

#: 15946 S1/NonTech Cust. Serv.
    28-Oct-92  04:58:13
Sb: HAPPY BIRTHDAY BILL
Fm: Paul Pignatelli 76367,2721
To: All

Today is Bill Gates's birthday, and even though we are an OS/2 only store, we
do recognise the extreme importance that Mr. Gates has played in the PC
revolution.  Bill Gates, through Microsoft, has made our lives more
productive, interesting, and exciting.  Could everyone reading this posting
please put their names below, and then perhaps someone could deliver this
message to The Chairman himself.

                                      HAPPY BIRTHDAY

                                          BILL GATES

                     FROM THE COMPUTING COMMUNITY

Signed, Paolo Pignatelli [The Corner Store]
...
...

There is 1 Reply.

#: 15960 S1/NonTech Cust. Serv.
    28-Oct-92  08:06:50
Sb: #15946-HAPPY BIRTHDAY BILL
Fm: Len Gray 71630,1703
To: Paul Pignatelli 76367,2721 (X)

..And many more happy ones to come, Bill!  -  Len Gray [Impact Software]

#: 15854 S1/NonTech Cust. Serv.
    27-Oct-92  07:34:01
Sb: WIN32/NT SDK Release 2
Fm: Don Perry 76676,1127
To: Non-Tech Support



I have ordered and received the complete July developers pre-release
(including all documentation) of the WIN32/NT SDK. I ordered it from Microsoft
over the phone and assumed that I was registered.

There is a new beta release supposedly being released this week but I'm
wondering if I am indeed registered for it as others who have bought the
pre-release SDK have gotten letters I haven't and Microsoft still continues to
send me "advertising" to get in to the WIN32/NT program which I already have.

Please check to see if I am indeed registered and if I will receive the
October release without any action on my part.

Information on my packing list from the SDK is:

     PERRY, DONALD
     3930 CRAL PLACE   <-----------(Should be "KRAL PLACE")
     PLEASANTON, CA 94588

  Ship date: 16-Sep-92

  Product:   ASSY WIN32 SDK (CDROM) DOC REL 1


Thanks, Don Perry



There is 1 Reply.

#: 15968 S1/NonTech Cust. Serv.
    28-Oct-92  11:20:44
Sb: #15854-WIN32/NT SDK Release 2
Fm: Stu Wiley 70473,1351
To: Don Perry 76676,1127

Don,  you're set.  It was sent out on the 26th.  You will want to hang onto
the following ID number adn reference it inthe future.  501124509.
 Stu Wiley
 Developer Service Team

#: 15948 S1/NonTech Cust. Serv.
    28-Oct-92  05:36:34
Sb: Microsoft Press
Fm: John B (Johannesburg) 73747,2703
To: sysop (X)

Could someone at Microsoft provide me a FAX no. for Microsoft Press. I'd like
to order the Windows Interface Application Design Guide and the easiest way to
do so is to send a credit card no. by FAX.

Thanks

John Ballinger (Johannesburg - South Africa)

There is 1 Reply.

#: 15970 S1/NonTech Cust. Serv.
    28-Oct-92  11:20:56
Sb: #15948-Microsoft Press
Fm: Stu Wiley 70473,1351
To: John B (Johannesburg) 73747,2703

John, 206/936-7329 and designate MSPRESS on the Cover sheet.  It should get
rerouted correctly.  Stu Wiley Developer Service Team

#: 16008 S1/NonTech Cust. Serv.
    28-Oct-92  16:44:44
Sb: #15617-MS: Oct SDK ships!!
Fm: John Mueller [DBA] 75300,576
To: Dwight Matheny/Microsoft 70750,2340 (X)

Well, I got my update today.  I haven't loaded it yet, but plan to this
evening sometime.

It's good to hear that Windows performance has improved.  It's likely that DOS
performance has as well based on what I've read in the beta package.

John Mueller

#: 15958 S1/NonTech Cust. Serv.
    28-Oct-92  08:02:30
Sb: Missing Manual for NT
Fm: Robert Eidson 70214,2115
To: sysop (X)

Sysop:
       I have discovered that I did not receive the Microsoft Windows 32-bit
Development Kit Guide to Programming.  What I did receive was:
  (1) Tools, (2) Programmer's Reference: Overviews, (3) Programmer's
Reference: Application Programming Intervace Part 1 & 2, (4) RPC Programmer's
Guide and Reverence, (5) Class Libraries Reference, (6) Class Libraries User's
Guide and (7) Run-Time Library Reference.

       Besides not having the Guide to Programming what else might I be
missing based on this list?  Would you have them sent to me as soon as
possible please.  They can be sent to:
       Robert Eidson
       Graphic Systems Applications, Inc.
       14825 S. W. Rainbow Drive
       Lake Oswego, Oregon 97035-2662 Thank you very much.

Bob



There is 1 Reply.

#: 16081 S1/NonTech Cust. Serv.
    29-Oct-92  10:50:35
Sb: #15958-Missing Manual for NT
Fm: Stu Wiley 70473,1351
To: Robert Eidson 70214,2115 (X)

Bob, Appreciate the conversation yesterday.  I'll check into a replacement
manual for you.
 Stu Wiley
 Developer Service Team

#: 16040 S1/NonTech Cust. Serv.
    28-Oct-92  23:28:49
Sb: MFC NT compile error
Fm: Nigel Chorley 100013,1717
To: sysop (X)

I am using the July 92 version.
I tried to compile the MFC library  (nmake model=N in dir mstools/mfc/src)
and got an error...

window.cpp (359):error C2446:'=' no conversion
      between 'int (__near__cdecl*)(void)' and 'void__near*'

All previous MFC lib files had compiled.
All MFC sample programs also compile and link OK (so far)

Can you help
Thanks, Nigel Chorley


There is 1 Reply.

#: 16089 S1/NonTech Cust. Serv.
    29-Oct-92  11:56:21
Sb: #16040-MFC NT compile error
Fm: Jerry Drain [Microsoft] 72350,2056
To: Nigel Chorley 100013,1717 (X)

Hi Nigel,

Please ask this question in Section 7 (Microsoft Tools).  They should be able
to help you.

Thanks,
  -- Jerry [@Microsoft]

#: 15959 S1/NonTech Cust. Serv.
    28-Oct-92  08:02:45
Sb: More DRIVERS congestion
Fm: Robert Eidson 70214,2115
To: sysop (X)

Sysop:
       I have the following drivers in my config.sys:

Device Name                                    Driver Size   For Application

DEVICE=C:\WINDOWS\HIMEM.SYS                    11552           DOS DEVICE =
C:\DOS\ANSI.SYS                        9029           DOS
DEVICE=C:\WINDOWS\SMARTDRV.EXE /DOUBLE_BUFFER   8335           DOS
DEVICE=C:\WINDOWS\PROTMAN.DOS /I:C:\WINDOWS    21664           Windows
DEVICE=C:\WINDOWS\WORKGRP.SYS                   7272           Windows
DEVICE=C:\WINDOWS\SMCMAC.DOS                   17344           Windows
DEVICE=C:\ASW410\ASPI4DOS.SYS                  10712           CDROM
DEVICE=C:\ASW410\ASWCDNEC.SYS /D:ASPICD0       13748           CDROM

In other words I have over 100K of device drivers needed for an environment
the consists of DOS, Windows for Workgroups.  I have NT but it has its own
configuration systems which should not impinge on any of this.  After getting
this development environment set up I went back to work and found that NMAKE
and NMK and CodeView would not even run.  Not enough room. Now I see why but
my question is what can I do so that I can do normal DOS and Windows
development without haveing multiple config.sys files and rebooting for each
situation?

Thanks for any help you can provide.

Bob Eidson




There are 2 Replies.

#: 16015 S1/NonTech Cust. Serv.
    28-Oct-92  18:22:23
Sb: #15959-More DRIVERS congestion
Fm: Steve Dirickson 70313,3252
To: Robert Eidson 70214,2115 (X)

>Device Name                                    Driver Size   For Application
>
>DEVICE=C:\WINDOWS\HIMEM.SYS                    11552           DOS DEVICE =
>C:\DOS\ANSI.SYS                        9029           DOS
>DEVICE=C:\WINDOWS\SMARTDRV.EXE /DOUBLE_BUFFER   8335           DOS
>DEVICE=C:\WINDOWS\PROTMAN.DOS /I:C:\WINDOWS    21664           Windows
>DEVICE=C:\WINDOWS\WORKGRP.SYS                   7272           Windows
>DEVICE=C:\WINDOWS\SMCMAC.DOS                   17344           Windows
>DEVICE=C:\ASW410\ASPI4DOS.SYS                  10712           CDROM
>DEVICE=C:\ASW410\ASWCDNEC.SYS /D:ASPICD0       13748           CDROM
>
>In other words I have over 100K of device drivers needed for an environment
>the consists of DOS, Windows for Workgroups.  I have NT but it has its own
>configuration systems which should not impinge on any of this.  After getting
>this development environment set up I went back to work and found that NMAKE
>and NMK and CodeView would not even run.  Not enough room. Now I see why but
>my question is what can I do so that I can do normal DOS and Windows
>development without haveing multiple config.sys files and rebooting for each
>situation?

PMFJI:

1) Add "device=C:\WINDOWS\EMM386.EXE NOEMS X=EC00-EFFF" (modify the 'X='
block to wherever your Etherlink card's buffer is, or (better yet) move the
buffer to EC00 in C:\WINDOWS\PROTOCOL.INI).
2) Add "DOS=HIGH,UMB"
3) Load SMCMAC.DOS high with 'devicehigh='
4) When it finds UMB space available, SmartDrive will automatically load as
much of itself high as it can (the AUTOEXEC.BAT part).
5) I'm pretty sure that the current version of ASPI4DOS is VDS (Virtual DMA
Spec) compliant, so you shouldn't need SmartDrive's double-buffer driver.
Check your Adaptec documentation (or call them and ask).
6) You might be able to load ASWCDNEC high--give it a shot or check the
docs/help line.
7) DON'T try to load PROTMAN.DOS high!



There is 1 Reply.

#: 16056 S1/NonTech Cust. Serv.
    29-Oct-92  07:04:19
Sb: #16015-More DRIVERS congestion
Fm: Jeff Thomson 71460,3222
To: Steve Dirickson 70313,3252 (X)

Steve,

> 5) I'm pretty sure that the current version of ASPI4DOS is VDS (Virtual
> DMA Spec) compliant, so you shouldn't need SmartDrive's double-buffer
> driver.

You're correct. SETUP always installs SMARTDRV w/ /DOUBLE_BUFFER, and I
always remove it ;-).

> 6) You might be able to load ASWCDNEC high--give it a shot or check the
> docs/help line.

My CD-ROM is a Toshiba, but I run its driver high w/ no problems.

#: 16091 S1/NonTech Cust. Serv.
    29-Oct-92  11:56:33
Sb: #15959-More DRIVERS congestion
Fm: Jerry Drain [Microsoft] 72350,2056
To: Robert Eidson 70214,2115 (X)

Hi Robert,

I see others have been able to jump in on this thread and help you.  I just
wanted to let you know there are two "setup" sections that you may be able to
get additional information from.  WinNT, Section 3: for system setup; and
MSWIN32, Section 2, for the SDK (development environment) Setup.

Thanks,
  -- Jerry [@Microsoft]

#: 16130 S1/NonTech Cust. Serv.
    29-Oct-92  15:38:18
Sb: 2nd SDK Ship Date
Fm: William H. Beebe, Jr. 70720,375
To: Dwight Matheny/Microsoft 70750,2340 (X)

I have mine, got it installed. The question I have is when we can expect SBPro
support with the attached CD-ROM player.

#: 16132 S1/NonTech Cust. Serv.
    29-Oct-92  16:19:22
Sb: WINDOWS NT BETA
Fm: Sung Y. Kim 70353,2743
To: all

How does one join Windows NT beta program. I have a capable machine with Sony
CD-ROM player. Thanks in advance.

#: 16095 S1/NonTech Cust. Serv.
    29-Oct-92  13:23:20
Sb: HELP!!!!!!
Fm: Ronald R. Martinsen 71202,1750
To: sysop (X)

Is the WINNT forum dead?  I left a message a couple of days ago and it still
has not been read.  I CAN NOT get Win32 working, but NT (October) is doing
GREAT!  I am using Procomm Plus for Windows to access compuserve within NT.  I
have only had Visual Basic 1 & 2.0 crash.

My problem with Win32 is that when you run setup it konks out after it tries
to copy WINSPOOL.DRV (according to what I can tell from reading the MST script
& INF file).

Ask the NT group to read my message!

Thanks, Ron

There are 2 Replies.

#: 16125 S1/NonTech Cust. Serv.
    29-Oct-92  14:38:37
Sb: #16095-HELP!!!!!!
Fm: Stu Wiley 70473,1351
To: Ronald R. Martinsen 71202,1750 (X)

Ron, You will probably want to put this in section 4 of the WINNT forum.  Some
of the folks are at the DDK conference, but the engineers are still live. Stu
WIley Developer Service Team

#: 16138 S1/NonTech Cust. Serv.
    29-Oct-92  16:44:37
Sb: #16095-HELP!!!!!!
Fm: Jerry Drain [Microsoft] 72350,2056
To: Ronald R. Martinsen 71202,1750 (X)

Hi Ron, and all,

If you notice service seems a little slower on the WINNT forum, please
exercise patience.  They are alive and well over there, but they are receiving
tons of questions regarding the new October release.  We expect that activity
to slowly shift into this forum once everyone has had a chance to get their
installations completed and many of their "new feature" questions answered.
This is just to let you know that they are answering questions as fast as they
can, and they haven't forgotten you.

Thanks,
  -- Jerry [@Microsoft]

#: 16009 S1/NonTech Cust. Serv.
    28-Oct-92  16:49:23
Sb: Memory Increase Advice
Fm: John Mueller [DBA] 75300,576
To: ALL

I just increased my system memory from 8 MB to 24 MB.  There were a few
messages on problems with systems that have over 16 MB a few weeks ago, but as
usual I failed to take notice.  Are there any caveats to using more than 16 MB
on an EISA system with a 16-bit IDE controller?  (My video display is also
16-bit as is just about everything else in my machine.)  TIA for any help <g>.

John Mueller

There is 1 Reply.

#: 16090 S1/NonTech Cust. Serv.
    29-Oct-92  11:56:27
Sb: #16009-Memory Increase Advice
Fm: Jerry Drain [Microsoft] 72350,2056
To: John Mueller [DBA] 75300,576 (X)

Hi John,

This question is better handled by the setup folks.  Please re-ask it in
WinNT, Section 3, (WinNT Setup).

Thanks,
  -- Jerry [@Microsoft]



There is 1 Reply.

#: 16189 S1/NonTech Cust. Serv.
    30-Oct-92  09:12:20
Sb: #16090-Memory Increase Advice
Fm: John Mueller [DBA] 75300,576
To: Jerry Drain [Microsoft] 72350,2056 (X)

No sweat <g>.

John Mueller

#: 16172 S1/NonTech Cust. Serv.
    30-Oct-92  01:57:36
Sb: WIN32 Shipment == WfW !
Fm: Wayne C. Cannon 72330,177
To: sysop (X)

I just received my WIN32 SDK update, or so the packing list said ("Assy Win32
SDK CD only release #2").  Upon opening the box, I found instead of the
expected CD-ROM, a set of 6 3.5-inch MS Word-for-Windows disks and a one-page
installation note.

What a let-down!

The shipment was labelled as Part Number: 226-175-021.

Please send me the correct update.  If you need anything, please contact me.

 Wayne Cannon
 EE Design Works
 1823 Manor Drive
 Santa Rosa, CA     95403-4141
 [phone]
 [phone] fax



There are 2 Replies.

#: 16177 S1/NonTech Cust. Serv.
    30-Oct-92  06:02:56
Sb: #16172-WIN32 Shipment == WfW !
Fm: John Oellrich [AT&T] 72611,1452
To: Wayne C. Cannon 72330,177

Wayne,

Hey keep the WFW 2.0 & order another WIN32 SDK. WFW 2.0 for 69 bucks is a real
steal ;->

John

#: 16193 S1/NonTech Cust. Serv.
    30-Oct-92  09:52:22
Sb: #16172-WIN32 Shipment == WfW !
Fm: Dwight Matheny/Microsoft 70750,2340
To: Wayne C. Cannon 72330,177

Sorry for the mistake. I've notified our manufacturing people and will take
care of getting you your update ASAP.

-Dwight (MS)

#: 15981 S1/NonTech Cust. Serv.
    28-Oct-92  13:27:47
Sb: Remote Login?
Fm: Andrew Potter 71075,614
To: all


Is there any way to log into an NT machine remotely using a modem or other
commmunication medium?

Thanks,

    Andrew

There is 1 Reply.

#: 16105 S1/NonTech Cust. Serv.
    29-Oct-92  13:32:13
Sb: #15981-Remote Login?
Fm: Bruce Ramsey/Microsoft 70324,2742
To: Andrew Potter 71075,614 (X)

Hi Andrew -

>> Is there any way to log into an NT machine remotely using a
  modem or other commmunication medium?

Today you can set up LAN Manager Remote Access Service 1.0 or 1.1

The way it works is:

  The RAS server code is installed on a LAN Manager OS/2 1.3
    server

  The RAS client code is installed on a client machine running
    MS-DOS or OS/2 1.x - RAS 1.1 has client code that integrates
    better with Windows 3.1

  This combination allows the RAS client to call in over telephone
    lines (modems) to access the RAS server code.  Once connected
    the RAS client and server code set up a connection for the
    client machine such that it appears to the client machine that
    they are a full participant on the network the OS/2 1.3 RAS
    server is on.  RAS 1.1 adds the option of connecting via X.25

So, if your machine running Windows NT is on the same network as a
  RAS 1.0 or 1.1 server, you can using the RAS 1.0 or 1.1 client
  code dial into that network, and access your machine running
  Windows NT over the network just as though you were on a machine
  attached to that network with a network adapter.  Well, of
  course, things happen slower due to the speed of the telephone
  line or modem

  As a full participant on the network, you can access any shared
    printer or disk on your machine running Windows NT, or use
    named pipe or RPC client apps to access any corresponding
    server code running on it.  You will also be able to
    administer that machine running Windows NT with the any remote
    admin tools for Windows NT that you have on your client.  For
    example, we will ship remotable admin tools with LAN Manager
    for Windows NT.  This will permit powerful remote admin over
    phone lines of machines running Windows NT

In other words (and in Windows NT terms), you can log onto the
  machine running Windows NT as a remote, or network user

We will ship both server and client versions of RAS that run on
  Windows NT, removing the present requirement that the RAS server

[More]

There are 2 Replies.

#: 16106 S1/NonTech Cust. Serv.
    29-Oct-92  13:32:20
Sb: #16105-Remote Login?
Fm: Bruce Ramsey/Microsoft 70324,2742
To: Bruce Ramsey/Microsoft 70324,2742 (X)

[Continued]

  be running OS/2 1.3, and the present limitation that the client
  can't be running Windows NT

I'm not sure from your question if this sort of "dial into the
  network over phone lines and access machines running Windows NT
  as I would over a network" remote access is what you're after

If you're asking can you dial in over phone lines, and remote the
  entire display of a machine running Windows NT to a client over
  the phone lines (and also remote the keyboard input and mouse
  input), then, no, this won't be in the first commercial release

Please let me know if this didn't address what you were asking
  about.  There may be better sections of either WINNT or MSWIN32
  to address follow-ups, but I'd rather better understand what
  you're after before referring you on

Bruce

#: 16214 S1/NonTech Cust. Serv.
    30-Oct-92  13:16:58
Sb: #16105-Remote Login?
Fm: Andrew Potter 71075,614
To: Bruce Ramsey/Microsoft 70324,2742 (X)

Bruce,

Thanks.  This is very helpful info.  What we are specifically interested in is
dialing in over a modem and getting to a command line (DOS prompt) for doing
some compilation and testing of text-only utilities. We'd just like to e able
to kick off a compile or run a utility or something like that without having
to drive to work, basically.  Or walk to the other room, for that matter.  If
I understand what you're saying, a remote login has access to tools and
applications that are implemented for remote access.  Or can the remote user
access any character-mode application?

Andrew

#: 16203 S1/NonTech Cust. Serv.
    30-Oct-92  11:51:13
Sb: Win NT tradmark instruct
Fm: Andrew Potter 71075,614
To: all

Could you please provide me with instruction as to the proper trademark
information to provide when referencing Windows NT in connection with
products we've developed for NT?

Thanks,

        Andrew


There is 1 Reply.

#: 16228 S1/NonTech Cust. Serv.
    30-Oct-92  15:39:04
Sb: #16203-Win NT tradmark instruct
Fm: Dwight Matheny/Microsoft 70750,2340
To: Andrew Potter 71075,614

There's an appendix in the release notes for the Oct SDK that covers just this
topic. Check out Appendix D "A short guide on how to use Windows NT
trademarks."

-Dwight (MS)

#: 16162 S1/NonTech Cust. Serv.
    29-Oct-92  20:35:44
Sb: Read Me
Fm: Ronald R. Martinsen 71202,1750
To:  72350,2056 (X)

Did you come up with any suggestions on how to get Win32 working on my machine
after reading my HELP!!! message?

Sorry if I sounded pushy, but I am just excited about NT.  I have been having
MUCH more sucess with the October release and I want to compare NT with Win32.

Thanks, Ron

There is 1 Reply.

#: 16244 S1/NonTech Cust. Serv.
    30-Oct-92  18:09:33
Sb: #16162-Read Me
Fm: Jerry Drain [Microsoft] 72350,2056
To: Ronald R. Martinsen 71202,1750

Hi Ron,

Sorry, no, I did not research your question.  My other responsibilities keep
me pretty tied up, and it's been quite a while since I've done anything with
installation issues; thus I directed you to the section where the expertise
is.  I would suggest re-posting your question in WinNT, Section 3; and
flagging it with an urgent title or something.  Most likely though they are
trying to address issues on a first come first server basis.  Be aware that
they've been pretty busy over there.

When you re-post your question, you'll probably have to give them some more
details on your hardware and software configuration.  With the little you've
posted here, it's difficult to tell why the installation crashed (if it did
crash) on that one file.  Was your harddisk full, do you have enough RAM, is
your hardware supported, did you get an error message, did you delete the old
Windows NT tree before installing; etc. etc.  Give them as much detail as
possible.

Thanks,
  -- Jerry [@Microsoft]

#: 15746 S1/NonTech Cust. Serv.
    25-Oct-92  07:06:57
Sb: Developers Network CD
Fm: Thomas Nielsen 100065,2167
To: All

Does anybody know *anything* about the Developers Network CD ?
When I call Microsoft Scandinavia, they keep telling me that they are waiting
for Microsoft US to ship the masters for the CD.
From what I have heard, the US developers has already got the CD

A clear answer would be nice..

Regards (from Denmark),

      Thomas


There is 1 Reply.

#: 15780 S1/NonTech Cust. Serv.
    26-Oct-92  09:51:21
Sb: #15746-Developers Network CD
Fm: Stu Wiley 70473,1351
To: Thomas Nielsen 100065,2167

Thomas,

The MSDN is a compilation of technical information for Windows developers. It
is a very comprehensive CD-ROM package with a great boolean search engine and
Windows Viewer.  You need to contact the subsidiary to purchase the product.
I suggest MSDenmark at 45.44.89.01.00

Stu Wiley Developer Service Team

#: 15838 S1/NonTech Cust. Serv.
    26-Oct-92  21:15:55
Sb: #15780-Developers Network CD
Fm: phil hystad 73260,114
To: Stu Wiley 70473,1351 (X)

Stu...

Can you help in clarifying which cd,s are which...

       ...first, there is the cdrom made available for (about $35 I think)
          that had the real nice (fancy) case.

               What is this CD called?

       ...Is this (above) CD different from the Developer Network CD?

       ...I assume that these CDs offer files that ARE NOT on the
          Winnt32 SDK CD which I have on order.

How do I get ahold of these other (How many?) CDs.

Thank you if you can clear this up, if you can't clear it up, thank you
anyway.

       phil



There is 1 Reply.

#: 15969 S1/NonTech Cust. Serv.
    28-Oct-92  11:20:52
Sb: #15838-Developers Network CD
Fm: Stu Wiley 70473,1351
To: phil hystad 73260,114 (X)

Phil, Several things for you:  You may want to post these in the MSDR forum,
but in the meantime- Yes, the "$30" CD-Rom is the Microsoft Developer Network
CD.  I don't know aout a fancy case, but essentially it's the CD I referenced
as the definitive compilation of Windows 16 bit development information.  The
second CD-Rom program we have avcailable is the Developers Preliminary
Win32SDK.  It sells for $399 US, or $69 without the hardcopy docs.  The docs
are the CD-Rom in Postscript file format, Windows Write file format and
Windows Help. This is specifically for 32bit WIndows NT development, and
contains the preliminary WIN32SDK, the C/C++ 32 bit compiler and the Windows
NT 3.1 operating system. There have been two releases, the July release and
the recently dropped October release.  The October release is essentially the
same OS as the Beta program, but contains all the needed development tools and
information while the beta program focuses on the end user operating system
only.
 Stu Wiley
 Developer Service Team




There is 1 Reply.

#: 16116 S1/NonTech Cust. Serv.
    29-Oct-92  13:37:32
Sb: #15969-Developers Network CD
Fm: Jerry Drain [Microsoft] 72350,2056
To: Stu Wiley 70473,1351 (X)

If I may add, the MSDN CD-ROM is not restricted to Windows 16 bit development.
It will cover other Windows development as well.

Thanks,
  -- Jerry [@Microsoft]



There is 1 Reply.

#: 16150 S1/NonTech Cust. Serv.
    29-Oct-92  18:02:07
Sb: #16116-Developers Network CD
Fm: phil hystad 73260,114
To: Jerry Drain [Microsoft] 72350,2056 (X)

Jerry...

I have a cirtificate to get the Developer's Network CD for $30. Unfortunately
the date of the end of the program says September 30th, 1992. Is the CD still
available for $30?

       phil



There is 1 Reply.

#: 16245 S1/NonTech Cust. Serv.
    30-Oct-92  18:09:38
Sb: #16150-Developers Network CD
Fm: Jerry Drain [Microsoft] 72350,2056
To: phil hystad 73260,114

Hi Phil,

I'm not sure where they are in the MSDN release right now.  You might call the
Developer Services Team and see what they can tell you (1-800-227-4679
x11771).  They can provide you with the most current release information.

Thanks,
  -- Jerry [@Microsoft]

#: 15857 S1/NonTech Cust. Serv.
    27-Oct-92  08:02:19
Sb: #15780-Developers Network CD
Fm: Chuck Johnson 73750,3111
To: Stu Wiley 70473,1351 (X)

Stu:

We're having trouble talking to the MSDN CD.  Cryptic error message from
_MSTEST.  Who should we call for help?  We've tried:

       [phone] x 11771 (back-of-the-CD-box number)
       [phone]

Shrugs or unsuccessful hipshot answers from those numbers.

Thanks for directing us.

Chuck Johnson




There are 2 Replies.

#: 15907 S1/NonTech Cust. Serv.
    27-Oct-92  16:01:50
Sb: #15857-Developers Network CD
Fm: Kyle Marsh 70712,220
To: Chuck Johnson 73750,3111 (X)

Post your problems to the MSDNLIB forum. The people who can help are there

Kyle MS Developer Netwrok



There is 1 Reply.

#: 15951 S1/NonTech Cust. Serv.
    28-Oct-92  07:14:03
Sb: #15907-Developers Network CD
Fm: Chuck Johnson 73750,3111
To: Kyle Marsh 70712,220 (X)

Kyle:

Much thanks.  Will do.

Chuck Johnson

#: 15967 S1/NonTech Cust. Serv.
    28-Oct-92  11:20:40
Sb: #15857-Developers Network CD
Fm: Stu Wiley 70473,1351
To: Chuck Johnson 73750,3111

chuck, Try 206/635-7033, this has been established specifically for MSADN
install/tech
 questions. Stu Wiley Developer Service Team

#: 16264 S1/NonTech Cust. Serv.
    30-Oct-92  20:51:57
Sb: MSDN CD Crash
Fm: Richard George 70640,2614
To: Sysop (X)

        I have been unable to get the MSDN CD to setup.  When I try to run
F:setup, I either get a not enough memory message (I have 16 meg plus a 20 meg
swap file) or it crashes the program loading it (either program manager or
file manager in win 3.1) causing an 'Exceed Segment Bounds (Read)' fault at
KERNEL UNDEFDYNLINK+00ef $tag$PROGMAN$Exceed Segment Bounds (Read)$KERNEL
UNDEFDYNLINK+00ef$mov     bx, es:[bx]$I have Dr. Watson logs for both crashes.
        Does anyone have any suggestions what is causing this to crash.  I
have the CD Technology drive and a DTC 3290 SCSI-2 EISA controller.

Thanks,

Richard




#: 15773 S3/SQL Server SDK
    26-Oct-92  08:11:32
Sb: #15600-SQLServer/NT/WIN16
Fm: dave skiba 70404,3556
To: Joe Marler 71075,416

would it be possible for me to get a copy of the install document also.

thanks dave skiba


#: 15833 S3/SQL Server SDK
    26-Oct-92  20:38:36
Sb: #15773-SQLServer/NT/WIN16
Fm: Joe Marler 71075,416
To: dave skiba 70404,3556

See the document 42INST.TXT, on Library 1 of the MSNETW forum.

Joe Marler

#: 15775 S3/SQL Server SDK
    26-Oct-92  08:47:21
Sb: #15600-SQLServer/NT/WIN16
Fm: John Stoddard 72400,2551
To: Joe Marler 71075,416

Good! We will be testing this stuff as soon as we get SNA and ODS for the
October release.

I got your mail with the SQL Server manual pages, but the mail tells me that
the message is in binary.  Any idea how to deal with this?  I never use
Compuserve except for NT support, so I am not all that facile with it...

John

#: 15834 S3/SQL Server SDK
    26-Oct-92  20:39:46
Sb: #15775-SQLServer/NT/WIN16
Fm: Joe Marler 71075,416
To: John Stoddard 72400,2551 (X)

I should have named it .ZIP, which means you must unzip it.  Note I have
uploaded an updated version of this document to Library 1 of the MSNETW forum.
It's called 42INST.TXT.

Joe Marler

There is 1 Reply.

#: 15877 S3/SQL Server SDK
    27-Oct-92  11:56:59
Sb: #15834-SQLServer/NT/WIN16
Fm: John Stoddard 72400,2551
To: Joe Marler 71075,416 (X)

Yep, I figured out how to get it.  Thanks.

#: 16148 S3/SQL Server SDK
    29-Oct-92  17:53:25
Sb: Installing SQL Server
Fm: James McDaniel [MS] 71075,415
To: Dan Sullivan 76327,1534 (X)

The file SQLOS2.TXT in section 3 (SQL Srv SDK) 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 Windows NT often fails, and it
contains a "manual install" procedure for completing the install by hand.

Concerning the "cannot connect to OS/2 subsystem" error, you might want to
check with other sections here.  That sounds like a more global problem with
your OS/2 subsystem or setup.

Sincerely,
James McDaniel
Microsoft SQL Server Support

#: 16149 S3/SQL Server SDK
    29-Oct-92  17:53:28
Sb: SQLServer 4.2 & NT
Fm: James McDaniel [MS] 71075,415
To: Christian Beaumont 100034,2326 (X)

The file SQLOS2.TXT in section 3 (SQL Srv SDK) 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 Windows NT often fails, and it
contains a "manual install" procedure for completing the install by hand.

Sincerely,
James McDaniel
Microsoft SQL Server Support




#: 15852 S4/API-User Interface
    27-Oct-92  06:25:50
Sb: How do I get user list?
Fm: Bob Byron 70107,1734
To: All



Regarding NT, I was wondering how, via the API, I would go about getting a
list of users that are logged in to a network.  I guess I would start with my
system, and want to get the name of the user logged in to it.  I guess I
would also need to know what other systems are on the network and get the name
of the user on each of those systems.  But, what are the calls involved?
Also, is there a way to find out what systems are on the network?  Or, do I
have to know that ahead of time.  These are probably more general questions,
but I am just learning this stuff.

Thanks, Bob

There is 1 Reply.


#: 15885 S4/API-User Interface
    27-Oct-92  12:58:42
Sb: #15852-How do I get user list?
Fm: Paul Tissue [Microsoft] 70744,24
To: Bob Byron 70107,1734 (X)

Hello Bob,

Please ask this question in section 12:API-RPC/WinNet.  The folks there know
about the networking APIs.  Thank you.

- Paul, Win32 SDK Developer Support

#: 15795 S4/API-User Interface
    26-Oct-92  12:57:52
Sb: MENUITEMTEMPLATE struct
Fm: Malinda Adams 72410,412
To: Steve Firebaugh 75430,412 (X)

Thanks for the DLGTEMPLATE info. We are also having a problem with the
LoadMenuIndirect call. It returns an error code of Invalid Data. It doesn't
seem that the MENITEMTEMPLATE structure is correct in the doc either. Do you
have any updated specs for that? Thanks for your help. Malinda Adams

#: 15898 S4/API-User Interface
    27-Oct-92  15:23:18
Sb: #15795-MENUITEMTEMPLATE struct
Fm: Steve Firebaugh [MS] 75430,412
To: Malinda Adams 72410,412 (X)

Malinda Adams,  You are correct that the resource format for the menu template
is not correctly documented.  This is part of a larger problem, namely that
none of the win32 resources (most of which have been 'widened') are documented
correctly.  We are working on a general solution.

Until then, I am including the documentation that I have at the end of this
posting.  I believe it to be correct, although I have not carefully verified
it, like I did for the dlgfmt.  I hope that it is useful to you.

Steve Firebaugh

------------------------------Menu Resources

Menu resources are composed of a menu header followed by a sequential list of
menu items.  There are two types of menu items:  popups and normal menu items.
The MENUITEM SEPARATOR is a special case of a normal menu item with an empty
name, zero ID, and zero flags.  The format for these types is shown here:
[Resource header (type = 4)]

struct MenuHeader { WORD    wVersion;       // Currently zero WORD
cbHeaderSize;   // Also zero };

These next items are repeated for every menu item. Popup menu items (signalled
by fItemFlags & POPUP): struct PopupMenuItem { WORD    fItemFlags; WCHAR
szItemText[]; };

Normal menu items (signalled by !(fItemFlags & POPUP)): struct NormalMenuItem
{ WORD    fItemFlags; WORD    wMenuID; WCHAR   szItemText[]; };

The wVersion and cbHeaderSize structure members identify the version of the
menu template.  They are both zero for Windows 3.0 but may be incremented with
future changes to the menu template. The WORD fItemFlags is a set of flags
describing the menu item.  If the POPUP bit is set, the item is a POPUP.
Otherwise, it is a normal menu component. There are several other flag bits
that may be set. Their values are as follows: #define GRAYED  0x0001  //
'GRAYED' keyword #define INACTIVE        0x0002  // 'INACTIVE' keyword #define
BITMAP  0x0004  // 'BITMAP' keyword #define OWNERDRAW       0x0100  //
'OWNERDRAW' keyword #define CHECKED 0x0008  // 'CHECKED' keyword #define POPUP
0x0010  // Used internally #define MENUBARBREAK    0x0020  // 'MENUBARBREAK'
keyword

[More]

There is 1 Reply.

#: 15899 S4/API-User Interface
    27-Oct-92  15:23:22
Sb: #15898-MENUITEMTEMPLATE struct
Fm: Steve Firebaugh [MS] 75430,412
To: Steve Firebaugh [MS] 75430,412 (X)

[Continued]

#: 15750 S4/API-User Interface
    25-Oct-92  10:56:48
Sb: #15693-SetWindowsHook Bug
Fm: Keith MacDonald 100041,235
To: Bob Landau [Microsoft] 70744,21 (X)

Bob,

In response to your questions about SetWindowsHookEx:
1) hHook is not NULL.
2) I'm calling CallNextHookEx from my HookProc.
3) My HookProc just looks for CAPS and NUM lock transitions and
   finishes with: return CallNextHookEx(...);
4) Sadly the October release hasn't reached our shores (England) yet!

The exact same HookProc works perfectly in a DLL.

Hope this helps,
Keith

#: 15925 S4/API-User Interface
    27-Oct-92  18:19:59
Sb: #15750-SetWindowsHook Bug
Fm: Bob Landau [Microsoft] 70744,21
To: Keith MacDonald 100041,235 (X)

Thanks Keith,

I'll look into this and post the results within the next 2 days.

Microsoft Developer Support

Bob Landau

#: 15776 S4/API-User Interface
    26-Oct-92  09:42:10
Sb: #15706-SetWindowsHook Bug
Fm: Bob Landau [Microsoft] 70744,21
To: neil colvin 71650,3517

Hello Neil,

The WIN32 SDK started shipping last week sometime. We are hoping to get the CD
to everyone in the US by end of this week. Please check out msg #15561 in
Section 1 for more details.

Microsoft Developer Support

Bob Landau

#: 15945 S4/API-User Interface
    27-Oct-92  23:17:04
Sb: CreateProcess broken?
Fm: Robert Zeff 70323,1251
To: all

CreateProcess was working in my program in the July release.  It doesn't work
for the October release.   I had to use Winexec instead.  Any clues?

-Robert




There is 1 Reply.

#: 15996 S4/API-User Interface
    28-Oct-92  15:33:46
Sb: #15945-CreateProcess broken?
Fm: Paul Tissue [Microsoft] 70744,24
To: Robert Zeff 70323,1251 (X)

Hello Robert,

As far as we know CreateProcess() works.  Some of our SDK samples, and not the
mention Windows NT itself, rely on CreateProcess().  You might want to take a
look at the following samples: DEB & Filer.

Since this is a base issue please ask this question in section 6:
API-Base/Security.  Also, please include a code snippet of how you are using
and calling this API so the folks there can see what you are attempting to do.
Thank you.

- Paul, Win32 SDK Developer Support

#: 15924 S4/API-User Interface
    27-Oct-92  18:19:55
Sb: #15710-DDE
Fm: Bob Landau [Microsoft] 70744,21
To: Howard Myers 76711,462 (X)

Howard,

I will look into this and get back to you within 2 days. Are these samples
that you're connecting your app up to in one of our SDK's? I'm trying to come
up with a similar test case. Lastly you are using the PackDDElParam(),
UnPackDDElParm() right?

Microsoft Developer Support

Bob Landau





There is 1 Reply.

#: 15954 S4/API-User Interface
    28-Oct-92  07:24:46
Sb: #15924-DDE
Fm: Howard Myers 76711,462
To: Bob Landau [Microsoft] 70744,21 (X)

Bob,

I'm using the Client and Server test apps provided in the DDEML sample
subdirectories of the NT SDK (\mstools\samples\ddeml\...).

I am not using PackDDElParam() or UnPackDDElParam() functions.  Quite
honestly, I didn't even know about them before this.  I looked in the DDEML
samples that come with the SDK, and they're not used there either; so I'm not
really sure how to use them.  However, the exceptions occur in
DispatchMessage() and GetMessage(), both before my window proc has ever gotten
the message to process.  Thus, I don't believe I would have gotten a chance to
use these functions yet at that point anyway.

Since the Server and Client apps. seem to work okay, it would seem to indicate
something in my app.  However, my code worked great with the July release, and
the exceptions are occurring in the API before I ever get a chance to handle
the messages.  If it is my problem, it seems that the most logical explanation
may be that I'm setting something up incorrectly when I establish myself as a
server, and when I get the ddeadvise.  Then those apps. send me back some
garbage (as a result of what I had previously sent them) and cause me to
generate an exception within the API.

Thanks for your help!

#: 16022 S4/API-User Interface
    28-Oct-92  19:15:17
Sb: #15710-DDE
Fm: Bob Landau [Microsoft] 70744,21
To: Howard Myers 76711,462 (X)

Howard,

I saw the reference to WM_DDE_ADVISE so I'd thought that the Client/Servers
were using the DDE protocol. That's why I made reference to UnpackDDElParam(),
PackDDElParam(), these are not appropriate for DDEML all the hand waving is
done for you.

Do you still have a copy of the July release of the SDK? If so a sanity check
of building and running the app would eliminate any possibility of an
accidently change.

If you wish you can send me a "trimmed" down version of your app which
demonstrates this problem and I'll look into this and if neccessary send this
off to development. Please if you do this keep the source down to what is
absolutely necessary but don't leave out anything needed to build it such as
headers/makefile. Post this as a zip file in this sections library.

Microsoft Developer Support

Bob Landau

#: 15786 S4/API-User Interface
    26-Oct-92  11:52:07
Sb: Fonts in Dialog Boxes
Fm: Howard Myers 76711,462
To: Microsoft

In the July release, compiling a resource file that had dialog boxes that
configured the font, didn't work.  (The dialog box worked, but the font never
changed.)  We worked on this problem with Bob Landau at the time.

Now that we have the October release, the first time we bring up our app.,
this feature works great.  However, if we bring our app. down and restart it,
we get the system default font -- but even worse, it uses the system metrics
for the font we requested! Thus, none of the text fits in the buttons, etc.
allocated for it.

The font does get loaded okay because I can force it into certain buttons by
issuing a WM_SETFONT command.  Also, it is obviously using the system metrics
for our font, not the default font.

Thanks for your help!

#: 16025 S4/API-User Interface
    28-Oct-92  19:15:34
Sb: #15786-Fonts in Dialog Boxes
Fm: Bob Landau [Microsoft] 70744,21
To: Howard Myers 76711,462 (X)

Howard,

If I hadn't seen this happen myself I would have thought you'd spent too much
time at the terminal :)

Unforturnately your right. It's broken. About all I can suggest for a quick
fix is to use the WM_SETFONT to explicitly change the font in the dialog box.
I *hate* to admit when I was closed this bug I never though that running the
app twice would make a difference. I re-open this of course.

Sorry

Microsoft Developer Support

Bob Landau




There is 1 Reply.

#: 16051 S4/API-User Interface
    29-Oct-92  05:57:07
Sb: #16025-Fonts in Dialog Boxes
Fm: Howard Myers 76711,462
To: Bob Landau [Microsoft] 70744,21 (X)

Thanks for looking into this.  We all let one slip by once in a while. I
probably would have done the same thing -- I initially though it was fixed
also, but then saw it act up.  It took me a while to determine what the key
was to duplicating it.  Once it broke, I couldn't get it to work at all.

Thanks again!

#: 15860 S4/API-User Interface
    27-Oct-92  09:11:35
Sb: File Open Common Dialog
Fm: Centre File 100015,3565
To: ALL

I am having problems with The File Open Common Dialog.

The first problem is that I cannot get OFN_ALLOWMULTISELECT to work when the
OFN_FILEMUSTEXIST and OFN_PATHMUSTEXIST flags are set. When You press the OK
button on the standard dialog, the whole list of files is rejected as an
invalid file name.

In order to get round this problem, I stoppped using the OFN_PATHMUSTEXIST and
OFN_FILEMUSTEXIST and tried to use a hook procedure to check the string passed
in the lpstrFile member of the OPENFILENAME structure. I then enountered the
2nd problem: The List box on the dialog has 23 files listed. The total length
of the string passed back in lpstrFile should be 249. nMaxFile is set to 256.
When the OK button is pressed, The file list is not placed in lpstrFile,
nFileOffset is set to -5, nFileExtension is set 1 and the first 4 bytes of
lpstrFile are garbage. Calling CommDlgExtendedError in my hook procedure
returns zero. The call to GetOpenFileName returns success.

The third problem is this: how do I use a hook procedure to dynamically
reallocate the lpstrfile buffer when FNERR_BUFFERTOOSMALL occurs and have the
DLL return the list of files?

If required, I can post some source code & the make file.


Thanks for your help,


Steve Brown

There is 1 Reply.

#: 16024 S4/API-User Interface
    28-Oct-92  19:15:28
Sb: #15860-File Open Common Dialog
Fm: Bob Landau [Microsoft] 70744,21
To: Centre File 100015,3565 (X)

Hello Steve,

There was a problem with the specifying multiple files in the July release of
the SDK; I've not had problems with this in the current builds.

If you are still have problems in the October release of the SDK please follow
up on this and we'll look into this.

Microsoft Developer Support

Bob Landau




There is 1 Reply.

#: 16045 S4/API-User Interface
    29-Oct-92  03:11:46
Sb: #16024-File Open Common Dialog
Fm: Centre File 100015,3565
To: Bob Landau [Microsoft] 70744,21 (X)

Bob,

Thanks for the info - I am waiting for the October beta release. Will I be
able to get it at the DDK conference in London on November 5th & 6th?

Regards,


Steve Brown.

There is 1 Reply.

#: 16118 S4/API-User Interface
    29-Oct-92  14:01:32
Sb: #16045-File Open Common Dialog
Fm: Bob Landau [Microsoft] 70744,21
To: Centre File 100015,3565

Steve,

In the US one needed both the SDK,OS and the DDK; they're seperate products.
The SDK does come bundled with the OS but the DDK only contains the headers,
libs, a few special tools and a "checked" version of the OS. The DDK does not
contain the compiler, etc need to build the device drivers.

I believe that the UK will handle this the same way; you'll need to be signed
up for both the SDK and DDK.

Microsoft Developer Support

Bob Landau

#: 15737 S4/API-User Interface
    24-Oct-92  13:59:53
Sb: #15522-Common Dialogs and Win32
Fm: Wim Bonner 72561,3135
To: Bob Landau [Microsoft] 70744,21 (X)

Thanks for the response.  I had forgoten about the Q_A directories on the CD,
(The CD Rom drive is not mine, so I don't have it all of the time)

I got the code, and copying the Structure initialization fixed my problem.

I was using code I had used before that was using memset to set the entire
structure to 0x0, then setting the particular values I needed.  (I think I
originally saw it done that way by Ray Duncan)

Now, very little problem.

Are the Print Dialogs different appearing in Win32 from Windows3.1?  I've

Do they differ with different printer installed, or just with certain options
greyed out?

Well, I'll probably have this stuff figured out before the weekend is over.

Wim

#: 16127 S4/API-User Interface
    29-Oct-92  15:03:34
Sb: #15737-Common Dialogs and Win32
Fm: Bob Landau [Microsoft] 70744,21
To: Wim Bonner 72561,3135 (X)

Hi Wim,

The only difference I found was in the secondary dialog box (More... button).
This dialog will reflect the capabilities of the printer. The generic dialog
box (first dialog you see) is the same for all printers.

Microsoft Developer Support

Bob Landau

#: 15855 S4/API-User Interface
    27-Oct-92  07:51:12
Sb: Win16 on NT
Fm: David Risack 75300,3712
To: All

What type of functions/ actions will cause win16 apps to fault under NT's API.
Is there a list of functions that may cause problems under NT for the win16
interface? Thanks, -->Dave

There is 1 Reply.

#: 16023 S4/API-User Interface
    28-Oct-92  19:15:21
Sb: #15855-Win16 on NT
Fm: Bob Landau [Microsoft] 70744,21
To: David Risack 75300,3712 (X)

David,

This is a very open ended question so I can really only give you a generalized
answer. In general any process *any* Win16 app which talks directly to
hardware will fault under NT. This is not absolute for instance NT does
emulate the screen buffer and serial port; MS-DOS apps won't break; I don't
believe Win16 apps do this though.

So for the most part a Win16 or MS-DOS app will work without problems on NT on
the retail release.

If you can be more specific on what actions you're interested in please post a
follow up in the WinNT forum section 4

Microsoft Developer Support

Bob Landau




There is 1 Reply.

#: 16178 S4/API-User Interface
    30-Oct-92  06:28:22
Sb: #16023-Win16 on NT
Fm: David Risack 75300,3712
To: Bob Landau [Microsoft] 70744,21 (X)

I'm trying to figure out how to debug a win-16 app under NT.  Currently the
App crashes on exit from it and on certain other occasions. How can I
currently debug I win-16 app. Even something that would tell me the last API
call made would give me a hint.

I'm using Borland C++.. Currently Turbo Debugger won't run under NT. The
windbg faults after loading the win16 subsystem.

Is there anyway to figure out what's going on? (without a way to debug under
NT it's hard to be more specific other than the app crashes-- we'll probably
have to start throwing message boxes or doing file output to try and figure
where if there is no current way to do this.)

Thanks, -->Dave

#: 16057 S4/API-User Interface
    29-Oct-92  07:33:24
Sb: DLGTEMPLATE
Fm: Colorado Memory Systems 76040,1260
To: Steve Firebaugh 75430,412 (X)

I am having problems creating DLGTEMPLATE's.  I found the file DLGFMT.ZIP with
the new format and I have questions about some of the fields.  The MenuName
and ClassName are of type [Name or Ordinal].  If I actually want to use a
string, is the type of the string WCHAR MenuName[], meaning that I have to
copy every byte to a WCHAR?  How do I null terminate this string?  The
explanations in DLGFMT.ZIP are a little confusing to me and I would greatly
appreciate it if you could provide some examples.  Thanks in advance.

There is 1 Reply.

#: 16139 S4/API-User Interface
    29-Oct-92  16:46:04
Sb: #16057-DLGTEMPLATE
Fm: Steve Firebaugh [MS] 75430,412
To: Colorado Memory Systems 76040,1260 (X)

1.  You are correct that the documentation in dlgfmt.zip is not especially
verbose or complete.  We are working on producing a more complete document
describing the Win32 resource format.  I am hoping to be able to upload it
some time next week.

2.  Yes, the strings in a DLGTEMPLATE resource are wide character, unicode
strings.  In order to null terminate them, simply end with 2 bytes containing
the value 0, rather than just one.

3.  However, this may not have to be an issue for you.  Notice that the system
will automatically translate unicode strings to ansi if you do not have
UNICODE defined in your source modules (and therefore link with the *A()
version of the API's rather than the *W() version).  I.e. if you are
ultimately calling CreateDialogIndirect() without defining UNICODE, then this
will map to CreateDialogIndirectA() which expects ansi strings.  It is only if
you do call CreateDialogIndirectW() that you should need to worry about
unicode strings in this context.  For more information, see the unicode
overview in the api32wh.hlp file.

4.  We do not have a useful sample for you at this point.  If you continue to
have problems, please continue to badger me here, and I may be able to produce
one in the next week.  We probably ought to be providing one by the next beta
release, at the latest.

Steve Firebaugh




There is 1 Reply.

#: 16180 S4/API-User Interface
    30-Oct-92  07:19:04
Sb: #16139-DLGTEMPLATE
Fm: Howard Myers 76711,462
To: Steve Firebaugh [MS] 75430,412 (X)

Steve,

In general, your comments about Unicode are correct.  However, I'm fairly
certain that it is INCORRECT for use with the DLGTEMPLATE structure.  I fought
this in the July release and this strings ALL had to be Unicode within these
structures.  This code is still working with the October release, so it
couldn't have changed.  The only difference is, I typically use
DialogBoxIndirect(), not CreateDialogIndirect(), but I'd be surprised if it
made a difference.

Also, just for anybody following this, for DialogBoxIndirect() the on-line
help (for October) as well as the manuals (for July) state that it wants a
handle to the dialog template.  I haven't tried going back with the October
release, but in July, this had to be an address, not a handle -- even though
3.x does allow a handle (in fact, I don't know if it allows an address).

CreateDialogIndirect() states that it wants an address, so there will probably
be no conflict there.

There is 1 Reply.

#: 16190 S4/API-User Interface
    30-Oct-92  09:28:57
Sb: #16180-DLGTEMPLATE
Fm: Steve Firebaugh [MS] 75430,412
To: Howard Myers 76711,462 (X)

Howard,   Thank you for the correction.  Looks like I will write that sample
sooner than I had thought.

Steve Firebaugh

#: 15983 S4/API-User Interface
    28-Oct-92  13:37:23
Sb: shift F12 key
Fm: michal 72340,73
To: SYSOP (X)

Dear SYSOP,

I have ported my application from Windows 3.1 to WIN32.  (I'm using
the WIN32 version from Sept 92)
I am having the following problem with the WIN32 version:

  The Shift F12 key does not generate a WM_KEYDOWN message.  Other keys,
  such as shift F11, are working fine.  Is shift F12 reserved by windows?
  and if so, can I change that?
  (NOTE: shift F12 was working for me in Windows 3.1)

Michal.


There is 1 Reply.

#: 16216 S4/API-User Interface
    30-Oct-92  13:31:15
Sb: #15983-shift F12 key
Fm: Paul Tissue [Microsoft] 70744,24
To: michal 72340,73

Hi Michal,

Thank you for reporting this problem.  I have verified it and escalated to our
developers.  I'll let you know what they have to say as soon as they get back
to me with the details.

- Paul, Win32 SDK Developer Support

#: 15982 S4/API-User Interface
    28-Oct-92  13:35:20
Sb: Font Common Dialog
Fm: michal 72340,73
To: SYSOP (X)

Dear SYSOP,

I have ported my application from Windows 3.1 to WIN32.  (I am using WIN32
from Sept. 92)
I am having the following problem with the WIN32 version:

  The ChooseFont() function is failing.  The CommDlgExtendedError()
  function is returning CDERR_STRUCTSIZE.  I am setting
        chf.lStructSize = sizeof(CHOOSEFONT);
  and I am picking up the correct commdlg.h.  What could be wrong?
  (Note: my code works fine in Windows 3.1).

Michal.


There is 1 Reply.

#: 16225 S4/API-User Interface
    30-Oct-92  15:33:08
Sb: #15982-Font Common Dialog
Fm: Paul Tissue [Microsoft] 70744,24
To: michal 72340,73

Hi Michal,

I'm not quite sure what you may be doing wrong but please take a look at the
code for th DEB sample (look at the function ChooseNewFont() in the file
DEBMISC.C).  I have used this same method both with the July and the October
release without a problem.  Let me know if this does not help track down the
problem and please post how you are calling this function and initializing the
structure.

- Paul, Win32 SDK Developer Support

#: 15984 S4/API-User Interface
    28-Oct-92  13:39:05
Sb: UnrealizeObject
Fm: michal 72340,73
To: SYSOP (X)

Dear SYSOP,

I have ported my application from Windows 3.1 to WIN32.  (I am using
the WIN32 version from Sept 92).
I am having the following problem with the WIN32 version:

  The function UnrealizeObject has been removed in WIN32.  Is that
  because objects are automatically unrealized? Or is there a different
  call I'm supposed to be making?


There is 1 Reply.

#: 16232 S4/API-User Interface
    30-Oct-92  16:03:41
Sb: #15984-UnrealizeObject
Fm: Bob Landau [Microsoft] 70744,21
To: michal 72340,73

Michal,

I'll attempt to answer this question ( you will get better response if you
post this in the GDI section: 5)

UnrealizedObject() was used in to cases

1) Set the orgin of Pattern Brushes so background and foreground patterns
match up.
   In Win32 the brush is already properly aligned so that this is unnecessary.

2) Reseting the color of a palette. This you'll need to post to section 5 of
this forum


Lastly the function *is* in the headers/libs for ease of porting to Win32
however the functionality of it's been removed.

Microsoft Developer Support

Bob Landau

#: 16184 S4/API-User Interface
    30-Oct-92  08:20:15
Sb: Win32s on 3.1
Fm: KENNETH R SCHROCK 70621,1521
To: Bruce Ramsey/Microsoft 70324,2742 (X)

        My NT editor has a problem running on 3.1 using the Win32s.
It appears that the problem is with the EM_SETHANDLE and EM_GETHANDLE
messages. When I open a file, it loads, but doesn't show in the editor window.
If I write something, and save, it save a file of 0 bytes. Could you give me
some guidance as to the problem, or possible solutions?

There is 1 Reply.

#: 16249 S4/API-User Interface
    30-Oct-92  18:29:24
Sb: #16184-Win32s on 3.1
Fm: Bob Landau [Microsoft] 70744,21
To: KENNETH R SCHROCK 70621,1521

Ken,

Can you please submit this to section 14 (Win32s). I realize this is somewhat
of a pain to re-submit the same question however you will get answers from
people more experience with problems specific to Win32s. This also has a
benefit to other in the forum since they can done load a specific section and
be guarenteed that it will contain all known information relavent to the
problem.

If for by chance you are not able to see section 14 check the section settings
in the forum options; more than likely that section will need to be enabled.

Microsoft Developer Support

Bob Landau

#: 16012 S4/API-User Interface
    28-Oct-92  17:55:21
Sb: InvalidRect
Fm: David Arathorn 70412,2772
To: Bob Landau, 70744,21 (X)

Hi Bob,

The InvalidRect problem has persisted into the October release.  The version
of WinChaos that you have will compile fine with a couple of WINAPIs added.

On reflection the problem may be due to some window manager LPCs sent or
processed or forwarded out of order, so in effect the little rect gets sent
just after the window manager has wiped the big rect.  The low frequency of
this problem is typical of asynchronous systems. It suggests someone forgot
some synchronizing code.

This may appear to you to be a nit, but there is a lot of extremely high value
added software using real time data displays now running under X (e.g.
trader's workstations) and just crying to ported to NT.

On the cheery side, I have run some brutal loading tests and the new release
passes with extreme grace.  Best I've seen.  Unix can't compare. The scheduler
is very even handed, the GUI never lost responsiveness (i.e it stayed paged
in) and with over 40 page faults per second the disk was getting hit only once
every few seconds.  That's smart paging!  Some VMS-wise friends suggest NT's
paternity might be showing here.  Are they right?

Dave



There is 1 Reply.

#: 16250 S4/API-User Interface
    30-Oct-92  18:29:28
Sb: #16012-InvalidRect
Fm: Bob Landau [Microsoft] 70744,21
To: David Arathorn 70412,2772

David,

I'll look into this over the week end.

Microsoft Developer Support

Bob Landau

#: 15878 S4/API-User Interface
    27-Oct-92  11:57:19
Sb: Missing WM_NCPAINT
Fm: Bruce Cowan 73650,32
To: all

There is a compatibility problem with Windows messages between NT and 3.1 (in
spite of all the fooforaw about them being identical).  NT doesn't send a
WM_NCPAINT when a window is first created and displayed, whereas 3.1 (and 3.0)
do.  All subsequent exposes of the window do get the WM_NCPAINT in NT, it is
only the first which is missing.  This problem is in both the July and October
releases.

Now, I don't really need this fixed, because it is easy to get around - I
simply check when I get the WM_PAINT and if I've never seen a WM_NCPAINT, I
do the NCPAINT work at that point.  (I am trapping WM_NCPAINT to paint a
special title line and system menu box.)

Bruce Cowan

There is 1 Reply.

#: 16109 S4/API-User Interface
    29-Oct-92  13:34:17
Sb: #15878-Missing WM_NCPAINT
Fm: Bob Landau [Microsoft] 70744,21
To: Bruce Cowan 73650,32 (X)

Hello Bruce,

I've added the following code to GENERIC

 WndProc:
  ...
 static fPaint = 0;
  ...
     case WM_NCPAINT:
        if ( fPaint == 0)
            fPaint = 1;
        return (DefWindowProc( hWnd, msg, wParam, lParam ));
  ...
     case WM_PAINT:
        if ( fPaint == 0 )
           OutputDebugString ("WM_PAINT called first\r\n");
        else if ( fPaint == 1 )
           OutputDebugString ("WM_NCPAINT called first\r\n");

        fPaint = 2;
  ...

Please paste the above code first into GENERIC and enter the following at the
command line

c:> windbg generic

You should see that message WM_NCPAINT called first in the Command box of
Windbg. Assuming the above is true add the same code to your sample and try it
again. You should see the same behavior. If not try to cut out as much code as
possible till you do get the same behavior.

If my assumption is wrong (Generic does not do as I stated above) let me know
and I'll ship you my version. If on the other hand a sequence of events in
your code prevents this behavior and removing that code will duplicate the
behavior ( the WM_NCPAINT message being displayed) please let me know and we
will look into this further.

Microsoft Developer Support

Bob Landau




There is 1 Reply.

#: 16126 S4/API-User Interface
    29-Oct-92  14:45:07
Sb: #16109-Missing WM_NCPAINT
Fm: Bruce Cowan 73650,32
To: Bob Landau [Microsoft] 70744,21 (X)

Bob, with your code in Generic, I get "WM_NCPAINT called first", in my winproc
I get "WM_PAINT called first" in NT and "WM_NCPAINT called first: in Win 3.1.
Here is the important info from my winproc (i.e. indicate which messages I trap
and swallow and which I pass on).

WinProc:

 switch (msg)
 {
  case WM_NCCREATE: ... goto Default;

  case WM_MOUSEACTIVATE:
    if (LOWORD(lParam) != HTCAPTION)
    {
      SetActiveWindow( GetParent(hWnd) );
      return MA_NOACTIVATE;
    }
    break;

  case WM_COMMAND: ... break;

  case WM_SYSCOMMAND: ... break;

  case WM_NCCALCSIZE: ... break;

  case WM_PAINT: ... goto Default;

  case WM_NCPAINT: ... break;

  case WM_ACTIVATEAPP:
    if ( ... )
      goto Default;
    return 1L;

  case WM_NCHITTEST:
    if ( ... )
      goto Default;
    return ...;

  case WM_CHAR: ... break;

  case WM_MENUSELECT:
    if (lParam != 0x0000FFFF)
      break;
    // fall thru...
  case WM_LBUTTONUP:
  case WM_MBUTTONUP:
  case WM_RBUTTONUP:
    break;

  case WM_MOVE: ... break;

  case WM_DESTROY: ... break;

  default:
  Default:
    return ( DefWindowProc(hWnd,msg,wParam,lParam) );
 }
 return 0L;

As I said at the beginning, I don't really care because I can do my work in
WM_PAINT, so I'm not going to start changing my code to see what message I trap
which causes the problem. Just so you are certain: there is *NO* difference in
my winproc between Win 3.1 and NT except a recompilation.

While I have your ear, could you please get someone to look into message 15914
- the need for this capability *CRITICAL* for my app (and it seems to me from
comments made at the PDC that the underlying capability is there, it just isn't
exposed in the API). Thanks.

Bruce Cowan

There is 1 Reply.

#: 16262 S4/API-User Interface
    30-Oct-92  20:23:30
Sb: #16126-Missing WM_NCPAINT
Fm: Bob Landau [Microsoft] 70744,21
To: Bruce Cowan 73650,32

Bruce,

I'll look at the code you sent in and bug this assuming I can't justify the
discrepentcy you've described. However since you stated this isn't a big issue
I'm going to address some more critical items first.

As to the issue you've described as critical message #15914 in the GDI
section. Petrus as brought your concern to the attention of Project
management. I do not understand all the issues you addressed in that thread
not being a GDI type but I have also sent mail around asking GDI specialists
around here to read your thread and look into implementing what you've asked.
This is about all either Petrus or I can do.

Microsoft Developer Support

Bob Landau




#: 15889 S5/API-GDI/Graphics
    27-Oct-92  14:22:08
Sb: Don't download Spice1.zi
Fm: Robert Zeff 70323,1251
To: all

Spice1.zip doesn't run under the October release.  I'll upload a new version
soon.  If you've already downloaded, and want another copy, send me a
self-addressed envelope & formatted floppy and I'll send you a new copy. (To
avoid the repreated download charges)

R. Zeff 4504 Bluffcreek Modesto, CA. 95355


#: 15913 S5/API-GDI/Graphics
    27-Oct-92  17:36:39
Sb: Making .FON files
Fm: Bruce Cowan 73650,32
To: Steve Firebaugh [MS] 75430,412 (X)

Steve,
Thanks for the makfon.zip sample. I have used it with the October release and
can make my font files ok.

However, it is still the case that a font which is identified as SYMBOL in the
header in the .FNT file (and the NT version of Font Editor agrees with this and
doesn't change the header at all when the file is opened and saved) shows up
during emumeration as ANSI_CHARSET and italics rather than as SYMBOL_CHARSET.

This needs to be fixed, and I wouldn't mind a work-around for the moment if you
can think of one.  I tried simply asking for italics rather than SYMBOL_CHARSET
but that does not give me the correct font, it seems to give me a slanted
version of my ANSI_CHARSET font.

Bruce Cowan

There is 1 Reply.

#: 15975 S5/API-GDI/Graphics
    28-Oct-92  11:47:19
Sb: #15913-Making .FON files
Fm: Steve Firebaugh [MS] 75430,412
To: Bruce Cowan 73650,32 (X)

Bruce,  I will not deny that there are problems in the font API (I ran into
several of them while writing "NTFonts").  However, I am unable to reproduce
the particular problem you are describing.  I start with the MAKFON files. I
edit the .FNT, change the charset to be symbol, save the file, rebuild the
FON, install it with the control panel, and then look at the logfont and
textmetric fields with NTFonts.  When I do this, I find that the charset which
I set with fontedit always shows up correctly in the logfont and textmetric
fields of the same name.  Based on this, I am guessing that we are not running
into a general problem.

Would you be willing to upload the *.FNT file which you are having problems
with??  This should allow me to reproduce the problem, and then I can dig
around in the bytes and see what is going on.  (Or, you could uuencode the
file and mail it to [e-mail].)  Thanks.

Steve Firebaugh



There is 1 Reply.

#: 16062 S5/API-GDI/Graphics
    29-Oct-92  08:08:00
Sb: #15975-Making .FON files
Fm: Bruce Cowan 73650,32
To: Steve Firebaugh [MS] 75430,412 (X)

Steve, I am on the track of solving my problem.  The only problem with the font
API in NT that I really have is that EnumFonts returns my fonts, my fonts
turned into italic, and my fonts turned into bold.  In 3.1 these extra copies
don't show up.  They were confusing me and then I ran into a couple of Windbg
bugs which confused me more, and the result was that I blamed NT when that is
not the problem.

Anyway, while I have your ear, I'll mention the two VERY SERIOUS Windbg
problems (I'll also post them in the correct section):

1. There are times when the Locals window shows completely the wrong values
   for the local variables. I have one function in which it always happens the
   second time I hit a breakpoint in the function. Closing and re-opening the
   locals window gets the correct values displayed. (This one led me on a real
   merry chase before I figured out it was the debugger.)

2. Windbg doesn't like one (at least) of my C source files. It refuses to load
   it either automatically (trace into it) or via File Open. I can't see
   anything strange about the file at all.

Thanks for your help with font problems.

Bruce Cowan

There is 1 Reply.

#: 16140 S5/API-GDI/Graphics
    29-Oct-92  16:46:09
Sb: #16062-Making .FON files
Fm: Steve Firebaugh [MS] 75430,412
To: Bruce Cowan 73650,32 (X)

Bruce,   I am glad that you were able to get past the font problem. I am
trying to determine the rationale for returning 4 fonts in the EnumFonts()
call when only 1 bitmap font is built into the FON file.  (I also get bold AND
italic, in addition to the 3 variants that you mentioned.)  The NTFonts
program (\mstools\samples\ntfonts) really is a good way to track down this
sort of behavior.  (Note, the program currently works better if you recompile
without having UNICODE defined.... then it lets you print :)

Thank you for posting the Windbg errors in section 7.  It is true that there
are serious problems with this debugger.  I do not KNOW what is causing the
second problem you list, but I have observed that if you #include one c file
in another, Windbg will not open the included one.

Steve Firebaugh

#: 15787 S5/API-GDI/Graphics
    26-Oct-92  11:53:07
Sb: S3 Drivers
Fm: Howard Myers 76711,462
To: Microsoft

I'm having problems with the S3 drivers in the October Beta release.

First, the SetDIBits with a 256 color logical palette is extremely slow.
(Approx. 10 times slower than 3.1) (Naturally, this assumes use of the
DIB_PAL_INDICES option. Using DIB_PAL_COLORS it is extremely fast, but
obviously gives incorrect results when 256 colors are required.)

Second, the colors being used out of the logical palette are incorrect. (I
don't know if they are being set incorrectly or loaded incorrectly.)

Finally, memory to memory bitblts are not working properly. This is a problem
that Bob Landau worked with us on, in the July release.  The VGA drivers now
seem to have the problem fixed, but the S3 drivers exhibit a similar problem,
although, not quite as severe.

We're supposed to show this product in the Microsoft 3rd party booth at Comdex
and, thus, time is of the essence.  These problems make showing such a product
very undesirable, both for how it makes our product look and yours.

Thanks!

#: 15822 S5/API-GDI/Graphics
    26-Oct-92  18:20:51
Sb: #15787-S3 Drivers
Fm: Petrus Wong [Microsoft] 70743,3355
To: Howard Myers 76711,462 (X)

Hi Howard:

 >>First, the SetDIBits with a 256 color logical palette is extremely slow.
(Approx. 10 times slower than 3.1)<<

 I'll follow up on this one.  Thanks for the feedback.

 >>Second, the colors being used out of the logical palette are incorrect. (I
don't know if they are being set incorrectly or loaded incorrectly.)

 Finally, memory to memory bitblts are not working properly.<<

 Howard, please be a bit more specific...  I don't have enough lead to go on
here. What exactly are the problems you are seeing and how to reproduce them?


 >>We're supposed to show this product in the Microsoft 3rd party booth at
Comdex and, thus, time is of the essence.  These problems make showing such a
product very undesirable, both for how it makes our product look and yours.<<

 Understood.  We'll see what we can do.  If you can provide us with a simple
test case or details on how to reproduce the problems, it will be great.

 thanks,
 petrus






There is 1 Reply.

#: 15850 S5/API-GDI/Graphics
    27-Oct-92  05:54:31
Sb: #15822-S3 Drivers
Fm: Howard Myers 76711,462
To: Petrus Wong [Microsoft] 70743,3355 (X)

As far as the palette is concerned, I have some additional info.  I tried
replacing the SetDIBits() with a loop using SetPixel().  This used the palette
properly, although it was even slower.  Thus, I'm sure the palette is being
properly defined/configured but for some reason is being improperly used.

When the palette is used improperly, the colors appear improperly, almost as
if there really aren't 256 colors.

As far as the memory to memory BitBlt() is concerned, when we originally send
the data directly to the screen, it appears one way.  At the same time we send
it to memory.  Later, if the screen needs repainted or is scrolled, we
BitBlt() it from our storage memory to screen memory.  This then appears
differently.  We pursued this problem with the July release and the VGA
drivers.  In that case, it was caused by the memory to memory BitBlt() and was
fixed in the October release.  What I'm afraid may have happened is that the
S3 driver was developed with some common code, before the fix went in. Bob
Landau worked on this problem with us and may be able to tell you exactly what
the cause was or who fixed it within Microsoft.

I will upload a copy of the Win 3.1 version, with a GIF the exhibits all of
the problems to GIF.ZIP in library 1 of this forum.  I haven't put it together
yet, so you may get this message before the file.  I'm uploading the 3.1
version since it exhibits exactly the same problems under NT, but will also
allow you to compare the speed difference of 3.1 vs. NT, as well as see it
working properly under 3.1.

As far as a small snippet is concerned, it's pretty hard to do, but I'll look
at it.  I'm also trying to discover alternative methods and work around the S3
driver problems, so this is keeping me quite busy.  We may be able to ship you
all of the source, and point you in the direction of the routine that is
actually at the center of the problem.  This is what we had to do previously
with Bob and the July release.  Let me know if that's acceptable.

Thanks for your prompt attention to this!

There is 1 Reply.

#: 15930 S5/API-GDI/Graphics
    27-Oct-92  18:24:58
Sb: #15850-S3 Drivers
Fm: Petrus Wong [Microsoft] 70743,3355
To: Howard Myers 76711,462 (X)

Hi Howard:

 >>As far as the palette is concerned, I have some additional info.  I tried
replacing the SetDIBits() with a loop using SetPixel().  This used the palette
properly, although it was even slower.  Thus, I'm sure the palette is being
properly defined/configured but for some reason is being improperly used.<<

 >>When the palette is used improperly, the colors appear improperly, almost
as if there really aren't 256 colors.<<

 I've just come across a similar problem on both S3 and MIPS.  Maybe they are
related.  I'll follow-up with the development.

 >>As far as the memory to memory BitBlt() is concerned, when we originally
send the data directly to the screen, it appears one way.  At the same time we
send it to memory.  Later, if the screen needs repainted or is scrolled, we
BitBlt() it from our storage memory to screen memory.  This then appears
differently.<<

 Okay, I think I have enough info to reproduce this one...

 >>I will upload a copy of the Win 3.1 version, with a GIF the exhibits all of
the problems to GIF.ZIP in library 1 of this forum.  I haven't put it together
yet, so you may get this message before the file.  I'm uploading the 3.1
version since it exhibits exactly the same problems under NT, but will also
allow you to compare the speed difference of 3.1 vs. NT, as well as see it
working properly under 3.1.<<

 Thanks very much, this will be very helpful.

 >>As far as a small snippet is concerned, it's pretty hard to do, but I'll
look at it.  I'm also trying to discover alternative methods and work around
the S3 driver problems, so this is keeping me quite busy.  We may be able to
ship you all of the source, and point you in the direction of the routine that
is actually at the center of the problem.  This is what we had to do
previously with Bob and the July release.  Let me know if that's acceptable.<<

 In most cases, a detail description on how to reproduce the problem or some
code fragment will be sufficient.  If this is not enough, we ususally prefer a
small (build-able) sample to demonstrate the problem.  (In the SDK samples

[More]

There is 1 Reply.

#: 15931 S5/API-GDI/Graphics
    27-Oct-92  18:25:05
Sb: #15930-S3 Drivers
Fm: Petrus Wong [Microsoft] 70743,3355
To: Petrus Wong [Microsoft] 70743,3355 (X)

[Continued]

directory, there is a small program called generic.  You may modify it by
plugging in the relevent functions to demonstrate the problem and send it (or
upload) to us.)  We probably don't need the entire source from you :)

 I'll be reproducing the problems on this end.  If I've trouble reproducing
them I will let you know.  But, I can always use your help...

 thanks,
 petrus




There is 1 Reply.

#: 15952 S5/API-GDI/Graphics
    28-Oct-92  07:14:55
Sb: #15931-S3 Drivers
Fm: Howard Myers 76711,462
To: Petrus Wong [Microsoft] 70743,3355 (X)

petrus,

Here's the code that does the actual displaying:

   SetDIBits( hdcBitmap, hMemBitMap, 0, 1, dptr, (LPBITMAPINFO)bi,
      DIB_PAL_COLORS);
   OldBitMap = SelectObject( hdcBitmap, hMemBitMap );
   if(!IsIconic(hWnd))
   {
      RealizePalette( hGifDC );
      SetWindowOrg(hGifDC, GetScrollPos(hWnd,SB_HORZ),
         GetScrollPos(hWnd,SB_VERT));
      BitBlt( hGifDC, X, GifY, DX, 1, hdcBitmap, start, 0, SRCCOPY);
   }
   BitBlt( hMemDC, X, GifY, DX, 1, hdcBitmap, start, 0, SRCCOPY);
   SelectObject( hdcBitmap,OldBitMap);

This has all been set up with a logical palette of 256 colors. hdcBitmap and
hMemBitMap are for a 1 pixel high, 1 scan line wide bitmap.  We build things
one scan line at a time.  hGifDC is for the screen.  hMemDC is for a full
bitmap that stores the entire image. This is later used when sections need
repainting, or are scrolled onto the screen.  It gets much more complicated to
show how dptr is setup, as well as X, DX, GifY, start, bi, etc.  To show all
of this, we'd be into a LOT of code.  But, the image does appear basically
correct, except for the colors and the speed.  Thus, the position arguments
must all be correct.  The palette must be properly established, or SetPixel()
would also display the wrong colors.  This also confirms that I must be using
the correct offset into the palette.

This last BitBlt shown above, is the suspect one.  It is blting from a 1 pixel
high memory bitmap, to our full memory bitmap.  Later, we do the following to
get from the full memory bitmap to the display, as required:

   hpalT = SelectPalette (hDC, hpal, FALSE);
   RealizePalette(hDC);
   hdcBits = CreateCompatibleDC(hDC);
   GetObject(hBitmap ,sizeof(BITMAP),(LPSTR)&bm);
   SelectObject(hdcBits,hBitmap );
   BitBlt(hDC,0,0,bm.bmWidth,bm.bmHeight,hdcBits,0,0,SRCCOPY);
   DeleteDC(hdcBits);
   SelectPalette(hDC,hpalT,FALSE);

where hBitmap is our full memory duplicate image.

Hopefully this will help some.  Thanks for your help!

There is 1 Reply.

#: 16159 S5/API-GDI/Graphics
    29-Oct-92  19:52:02
Sb: #15952-S3 Drivers
Fm: Petrus Wong [Microsoft] 70743,3355
To: Howard Myers 76711,462 (X)

Hello Howard,

 Thanks for the code fragment and the program for demonstrating the problem.
The color was definitely wrong.  However, I doubt that's the S3 driver.  It is
probably a bug in the RealizePalette api or the window messages associated to
palette change (running the program on MIPS also gives the wrong color.) This
is the same bug that I came across earlier. I will follow this up with the
development to get this fix.

 However, I am not seeing the bitblt problem you mentioned in the read.me.
The scrolling and repainting was fast.  I don't see the slight change in
color.

 I will definitely raise the issue of performance of S3 with the developer.

 thanks,
 petrus





There is 1 Reply.

#: 16179 S5/API-GDI/Graphics
    30-Oct-92  06:46:32
Sb: #16159-S3 Drivers
Fm: Howard Myers 76711,462
To: Petrus Wong [Microsoft] 70743,3355 (X)

petrus,

Thanks for the info.  As far as the bitblt() problem is concerned, I hope it
will disappear when the color problem is fixed.  This problem doesn't appear
when using SetPixel(), which gives the correct colors; so I hope that means
once the colors are corrected, it won't appear.  Thus, it may not be of a
large concern (I hope!).

If the color problem were caused by RealizePalette(), wouldn't it also appear
when using SetPixel()?  I'm not sure -- just seems like it to me.

Finally, I know the answer to this one, but I have to ask anyway.  Is there
any chance of getting an updated driver and/or patch for this by Comdex. We're
demonstrating in the Microsoft 3rd party booth, and this is the best part of
our show -- even though it's not the meat of our product.

Thanks again.

There is 1 Reply.

#: 16226 S5/API-GDI/Graphics
    30-Oct-92  15:34:40
Sb: #16179-S3 Drivers
Fm: Petrus Wong [Microsoft] 70743,3355
To: Howard Myers 76711,462

Howard:

 >>If the color problem were caused by RealizePalette(), wouldn't it also
appear when using SetPixel()?  I'm not sure -- just seems like it to me.<<

 Good point, I'll keep this in mind...

 >>Finally, I know the answer to this one, but I have to ask anyway.  Is there
any chance of getting an updated driver and/or patch for this by Comdex. We're
demonstrating in the Microsoft 3rd party booth, and this is the best part of
our show -- even though it's not the meat of our product.<<

 Howard, it's not likely that we'll release an official update before the next
beta. However, you should contact our developer relation folks to see if there
is going to be a "Comdex" build of the system.  If so, you will have to get
the system from them.

 I hope that helps,

 thanks,
 petrus

#: 15914 S5/API-GDI/Graphics
    27-Oct-92  17:37:34
Sb: Drawing on DIBs
Fm: Bruce Cowan 73650,32
To: all

Windows 3.1 provided a DIB driver (called DIB.DRV) which allowed one to draw on
DIBs while still maintaining access to the memory representing the DIB.  One
could then directly manipulate that memory or copy it to a display (using
StretchDIBits) or write it to a file.  This is documented in the 3.1 SDK help
file under Contents->Overviews->Video Techniques.  We use this ability in our
application (except for direct manipulation of the bits) and I can't figure out
how to do the same in NT.

I've heard that standard display drivers know how to draw on DIBs in NT (this
was mentioned at the PDC in July), but I can't figure out how to create the
appropriate HDC and DIB; calling CreateDC("DIB", ...) as in 3.1 doesn't work.
I first thought that CreateCompatibleDC and CreateDIBitmap would do the trick,
but that seems to create a device-dependent bitmap when I really need a DIB (at
least that is what the docs claim).  Besides, it doesn't give me the address of
the DIB bits and I need that to pass to StretchDIBits.

I know that, in theory, one can draw on a device-dependent bitmap and use
GetDIBits to copy the data to a DIB, but that is slow and awkward in comparison
to the simple use of the DIB driver.

Can anyone point me in the right direction here?  Thanks.

Bruce Cowan



There is 1 Reply.

#: 16155 S5/API-GDI/Graphics
    29-Oct-92  18:28:25
Sb: #15914-Drawing on DIBs
Fm: Petrus Wong [Microsoft] 70743,3355
To: Bruce Cowan 73650,32 (X)

Hello Bruce,

 I don't think this is supported currently...

..petrus



There is 1 Reply.

#: 16186 S5/API-GDI/Graphics
    30-Oct-92  08:38:54
Sb: #16155-Drawing on DIBs
Fm: Bruce Cowan 73650,32
To: Petrus Wong [Microsoft] 70743,3355 (X)

Ouch, any word on when. I need this capability for our app which is supposed to
demo in the Microsoft booth at Comdex! (I can obviously implement all my own
drawing primitives on DIBs, but not in time for Comdex.) It seems from what I
heard at the PDC that the underlying ability is there and it is just not
exposed in the API.

Bruce

There is 1 Reply.

#: 16235 S5/API-GDI/Graphics
    30-Oct-92  16:06:58
Sb: #16186-Drawing on DIBs
Fm: Petrus Wong [Microsoft] 70743,3355
To: Bruce Cowan 73650,32

Hi Bruce,

 >>Ouch, any word on when. I need this capability for our app which is
supposed to demo in the Microsoft booth at Comdex! (I can obviously implement
all my own drawing primitives on DIBs, but not in time for Comdex.) It seems
from what I heard at the PDC that the underlying ability is there and it is
just not exposed in the API.<<

 I'm afraid we do not plan to support that on Windows NT.  One of the reasons
being that the DIB.drv was not a real driver and is actually part of the
graphics engine.  This extension was necessary for the multimedia in Win3.1.
Somewhere along the line, Windows NT decided that this is not the right
approach.  So, we are not going to support that.  This view may change in the
future.  But, I don't want to keep your hope up that any change will be in
time for Comdex.

 thanks,
 petrus

#: 16033 S5/API-GDI/Graphics
    28-Oct-92  20:40:43
Sb: Real-time animation??
Fm: Joe Peterson[CyberStore] 76150,1714
To: All

Hi!

Does NT support *real-time* animation (*not* framing or bitblt-ing)?  If so,
how well?  That is, is performace acceptable?

Thanks!

(BTW: for lack of a better place to put this question, I asked it here.  If
there is a more appropriate place, please let me know.)

jep



There is 1 Reply.

#: 16143 S5/API-GDI/Graphics
    29-Oct-92  16:49:41
Sb: #16033-Real-time animation??
Fm: Petrus Wong [Microsoft] 70743,3355
To: Joe Peterson[CyberStore] 76150,1714 (X)

Hi Joe:

 >>Does NT support *real-time* animation (*not* framing or bitblt-ing)?  If
so, how well?  That is, is performace acceptable?<<

 Not yet, we don't have a multimedia SDK for Windows NT yet.  But, you may try
to run Windows 16 bit multimedia applications on the WOW layer.

 >>(BTW: for lack of a better place to put this question, I asked it here.  If
there is a more appropriate place, please let me know.)<<

 We really don't have a place for this yet...

 thanks,
 petrus




There is 1 Reply.

#: 16160 S5/API-GDI/Graphics
    29-Oct-92  20:06:55
Sb: #16143-Real-time animation??
Fm: Joe Peterson[CyberStore] 76150,1714
To: Petrus Wong [Microsoft] 70743,3355 (X)

 > Not yet, we don't have a multimedia SDK for Windows NT yet.

Bummer!  Are there plans in the works?

 > But, you may try to run Windows 16 bit multimedia applications on the WOW
layer.

I really need pre-emptive multitasking in this app; threads and all that rot.
Win16 won't cut it, Windows multimedia or not.

Thanks for the quick reply.  I'll "keep my eyes peeled" for further
developments.

jep



There is 1 Reply.

#: 16239 S5/API-GDI/Graphics
    30-Oct-92  16:58:50
Sb: #16160-Real-time animation??
Fm: Petrus Wong [Microsoft] 70743,3355
To: Joe Peterson[CyberStore] 76150,1714 (X)

Hi Joe:

 >> Not yet, we don't have a multimedia SDK for Windows NT yet.
 >Bummer!  Are there plans in the works?

 We do have plans on that but I don't have specific time frame for you as to
when this is going to be available.

 thanks,
 petrus

#: 15910 S5/API-GDI/Graphics
    27-Oct-92  16:25:00
Sb: MIPS blt is sloooow!!!
Fm: Lanre Amos 70550,2360
To: microsoft

Blt functions on the MIPS (StretchBlt etc) is slooooooooow on the October
build. Much slower than on the July PDC! Any ideas what's going on here?

-Desperately needing help!!



There is 1 Reply.

#: 16027 S5/API-GDI/Graphics
    28-Oct-92  19:18:49
Sb: #15910-MIPS blt is sloooow!!!
Fm: Petrus Wong [Microsoft] 70743,3355
To: Lanre Amos 70550,2360 (X)

Hi Lanre:

 >>Blt functions on the MIPS (StretchBlt etc) is slooooooooow on the October
build. Much slower than on the July PDC! Any ideas what's going on here?<<

 The GDI group will be working on the performance for the next release...
 Just curious, how much memory you have for your MIPS machine?   We usually
recommend
 more memory for the MIPS than on the x86.

 petrus




There is 1 Reply.

#: 16082 S5/API-GDI/Graphics
    29-Oct-92  10:59:22
Sb: #16027-MIPS blt is sloooow!!!
Fm: Lanre Amos 70550,2360
To: Petrus Wong [Microsoft] 70743,3355 (X)


I have a MAXIMALLY configured machine, Petrus!! 64Meg of RAM, 600 MByte HD
etc, etc! I think this may very well kill the MIPS machine! No C++ and now
this! BTW, I'm about to blow off the October build and reinstall the July PDK
and if I can't get the DDK to work with that, I'll just junk the whole box!
Pretty drastic, I know but it's still better to cut my losses early!!

It's a shame though. I was beginning to really like the MIPS machine!

-L.

There is 1 Reply.

#: 16240 S5/API-GDI/Graphics
    30-Oct-92  16:58:57
Sb: #16082-MIPS blt is sloooow!!!
Fm: Petrus Wong [Microsoft] 70743,3355
To: Lanre Amos 70550,2360

Hello Lanre,

 >>I have a MAXIMALLY configured machine, Petrus!! 64Meg of RAM, 600 MByte HD
etc, etc! I think this may very well kill the MIPS machine! No C++ and now
this! BTW, I'm about to blow off the October build and reinstall the July PDK
and if I can't get the DDK to work with that, I'll just junk the whole box!
Pretty drastic, I know but it's still better to cut my losses early!!

 It's a shame though. I was beginning to really like the MIPS machine!<<

 It's sad to hear that...Thanks for bringing this to our attention.  I'll
forward your feedback to the developers.

 petrus

#: 16197 S5/API-GDI/Graphics
    30-Oct-92  10:52:48
Sb: Bug in StretchBlt
Fm: Len Gray 71630,1703
To: All

I'm having a problem getting StretchBlt to perform a mirror image flip on a
bitmap.  The following API call will correctly vertically flip a 32 x 32
bitmap under Windows 3.1:

    StretchBlt (hToDC, 0, 31, 32, -32, hFromDC, nFromX, nFromY, 32, 32);

This call does not operate correctly under Windows NT (Oct).  I've tried all
sorts of values to see if I could coax it to work one way or another, but no
luck.  My research leads me to believe that the above values are correct for
what I want to do, but the top and left edge of the target bitmap are
incorrect after the call.

Please note that I think the documentation for mirror imaging using StretchBlt
has been incorrect since day one.  All docs state that you use opposite signs
on the source and dest height or width to do a mirror image. I've never been
able to get that one to work.  The above values, however, have worked in the
past and make logical sense as well.

Thanks for taking a look at this one for me!

    Len



There is 1 Reply.

#: 16212 S5/API-GDI/Graphics
    30-Oct-92  13:09:10
Sb: #16197-Bug in StretchBlt
Fm: Steve Firebaugh [MS] 75430,412
To: Len Gray 71630,1703 (X)

Len,  StretchBlt() is able to produce mirror images in the October beta
release.  Please have a look at the \q_a\samples\streblt sample.  By loading a
source bitmap, then filling in values similar to the ones you listed, I was
able to get the StretchBlt() api to produce a mirror image.  I tested this on
both the VGA and the VRAM7.

Please have a look at the streblt sample, and if you continue to have
problems, get back to us.

Steve Firebaugh




There is 1 Reply.

#: 16241 S5/API-GDI/Graphics
    30-Oct-92  17:26:16
Sb: #16212-Bug in StretchBlt
Fm: Len Gray 71630,1703
To: Steve Firebaugh [MS] 75430,412 (X)

Hi, Steve

Thank you very much for checking into my StretchBlt report so thoroughly. I'll
take a look at the samples and see if I can find how I have strayed from the
proper usage.

I'll let you know if I have anything worthwhile to report.

Thanks again!

   Len

#: 16038 S5/API-GDI/Graphics
    28-Oct-92  23:02:19
Sb: Screen Saver
Fm: Mark Gamber 76450,2754
To:  76450,2754 (X)

This may be trivial, but what is up with the Screen Saver library? I've done
screen savers for 3.1 and tryed porting....oops. Then I looked at SCRNSAVE.H
and can't make heads or tails out of it. Finally, I get an unresolved
reference from the linker, looking for _WinMain@16. If anyone has any hints,
I'm all ears (no pun intended).
      Mark

There is 1 Reply.

#: 16142 S5/API-GDI/Graphics
    29-Oct-92  16:49:36
Sb: #16038-Screen Saver
Fm: Petrus Wong [Microsoft] 70743,3355
To: Mark Gamber 76450,2754 (X)

Hello Mark:

 >>This may be trivial, but what is up with the Screen Saver library? I've
done screen savers for 3.1 and tryed porting....oops. Then I looked at
SCRNSAVE.H and can't make heads or tails out of it. Finally, I get an
unresolved reference from the linker, looking for _WinMain@16. If anyone has
any hints, I'm all ears (no pun intended).<<

 The scrnsave.h header file is used for writing screen savers for the Desktop
control panel applet.  It defines the interface between the applet and your
screen saver program. Your screen saver will be exporting the
ScreenSaveConfigureDialog function if your screen saver has user configurable
items.  The function will be called when the user press the "Setup..." button
in the Desktop applet.

 Your screen saver program will also export the ScreenSaverProc() window
procedure and the default window procedure for this function is the
DefScreenSaverProc().

 Also, your screen saver should have a procedure called
RegisterDialogCleasses(). This function will be called by the Desktop applet
before it makes any call to bring up your user configuration dialog so that
your screen saver will have a chance to register any private control class you
may use for your configuration dialog.

 As for the unresolved reference, this is due to the fact that we have changed
our calling convention to standard calling convention.  Thus, your WinMain
should be declared as int WINAPI WinMain().  Checkout the ntwin32.mak in the
\mstools\h directory and the SDK samples in the \mstools\samples directory.
These samples have been updated to use the new calling convention and uses the
ntwin32.mak in the makefile.

 Hope this helps,

 petrus



There is 1 Reply.

#: 16164 S5/API-GDI/Graphics
    29-Oct-92  21:09:00
Sb: #16142-Screen Saver
Fm: Mark Gamber 76450,2754
To: Petrus Wong [Microsoft] 70743,3355 (X)

Well, I have done everything you've described. It's really not *much*
different than Win31's screen savers, excepting global variable changes and
calling conventions. What's throwing me is the only error I get is on the
WinMain which was previously provided by the SCRNSAVE.LIB file. How to go
about writing a screen saver using your own WinMain is beyond me because I
never had to do it before. I recheck the examples and so on but I've done that
a million times already with no luck. Well, maybe not a million, but...heh
heh. If you can provide a filename on the CD, some example code...any shortcut
at all, I will be eternally grateful. Maybe even longer.
   Mark

There is 1 Reply.

#: 16247 S5/API-GDI/Graphics
    30-Oct-92  18:12:32
Sb: #16164-Screen Saver
Fm: Petrus Wong [Microsoft] 70743,3355
To: Mark Gamber 76450,2754 (X)

Hi Mark:

 >>Well, I have done everything you've described. It's really not *much*
different than Win31's screen savers, excepting global variable changes and
calling conventions. What's throwing me is the only error I get is on the
WinMain which was previously provided by the SCRNSAVE.LIB file. How to go
about writing a screen saver using your own WinMain is beyond me because I
never had to do it before. I recheck the examples and so on but I've done that
a million times already with no luck. Well, maybe not a million, but...heh
heh. If you can provide a filename on the CD, some example code...any shortcut
at all, I will be eternally grateful. Maybe even longer.<<

 Try linking with -entry:mainCRTStartup instead.  The screensave.lib is
exporting _main instead of _WinMain.

 thanks,
 petrus






There is 1 Reply.

#: 16263 S5/API-GDI/Graphics
    30-Oct-92  20:42:02
Sb: #16247-Screen Saver
Fm: Mark Gamber 76450,2754
To: Petrus Wong [Microsoft] 70743,3355 (X)

Looks reasonable to me! Thanks a bunch. Eternity sure is a long time... <g>
   Mark

There is 1 Reply.

#: 16265 S5/API-GDI/Graphics
    30-Oct-92  21:11:37
Sb: #16263-Screen Saver
Fm: Mark Gamber 76450,2754
To: Mark Gamber 76450,2754 (X)

Petrus,
   As evidenced by the upload, it sure did solve the problem. Thanks again.
Sti Still, I hope the screen saver library is cleaned up a little bit before a
general release is made....it's not very apparent.  : )
   Mark




#: 15754 S6/API-Base/Security
    25-Oct-92  15:03:16
Sb: #15544-Messages to other app.
Fm: John Hall [MS SDE] 70750,2341
To: Christian Betrisey 76600,1450 (X)

Try this:
Have each .exe attach to the dll.
Each .exe will call an init function in the dll, supplying a HWND and
a name.
To send a message, call a function with a name and a handle to a shared
memory block (see shrmem.zip in Porting from OS/2)
The dll will translate name to HWND and post a message.

Or you could use Queues, which is an implementation of OS/2 type queues
built with shrmem.zip that I will be posting within 2 weeks.
[I'll be updating all my stuff for the beta within 2 weeks.]


#: 15825 S6/API-Base/Security
    26-Oct-92  20:27:16
Sb: New KB articles
Fm: Eric Sassaman/Microsoft 75430,411
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: October 1992 Windows NT Release Announcement             [P_W32dev]
 Q89848
 ------------------------------------------------------------------------
 PRB: Sound Blaster Card Continuously Repeats .WAV File        [P_W32dev]
 Q89064
 ------------------------------------------------------------------------
 INF: Possible Causes for Fatal System Error 0x0000000E        [P_W32dev]
 Q89099
 ------------------------------------------------------------------------
 PRB: Windows NT Boots, but Looks for Wrong Boot Directory     [P_W32dev]
 Q89165
 ------------------------------------------------------------------------
 INF: Win32 Subsystem Object Cleanup                           [P_W32dev]
 Q89290
 ------------------------------------------------------------------------
 INF: Unicode Conversion to Integers                           [P_W32dev]
 Q89295
 ------------------------------------------------------------------------
 INF: How HEAPSIZE/STACKSIZE Commit > Reserve Affects Execution[P_W32dev]
 Q89296
 ------------------------------------------------------------------------
 INF: November DDK Conference in Europe                        [P_W32dev]
 Q89340
 ------------------------------------------------------------------------
 INF: Fault Tolerance on Symmetric Multiprocessor Machines     [P_W32dev]
 Q89342
 ------------------------------------------------------------------------
 INF: .RES Files Produced by July Release Makefiles            [P_W32dev]
 Q89344
 ------------------------------------------------------------------------

[More]

There is 1 Reply.

#: 15826 S6/API-Base/Security
    26-Oct-92  20:27:22
Sb: #15825-New KB articles
Fm: Eric Sassaman/Microsoft 75430,411
To: Eric Sassaman/Microsoft 75430,411 (X)

[Continued]

 INF: Submitting Bug Reports for Windows NT                    [P_W32dev]
 Q89371
 ------------------------------------------------------------------------
 PRB: I/O Stream Header Files Not Included in July Release     [P_W32dev]
 Q89419
 ------------------------------------------------------------------------
 INF: Base Date for Time Differs Between NT and C/C++ 7.0      [P_W32dev]
 Q89580
 ------------------------------------------------------------------------
 PRB: Problems with 3.1 COMM.DRV on Certain DEC Machines       [P_W32dev]
 Q89690

  Eric Sassaman
  Microsoft NT Support

#: 15827 S6/API-Base/Security
    26-Oct-92  20:27:29
Sb: Doc Bug - OpenFile()
Fm: Eric Sassaman/Microsoft 75430,411
To: George Smythe 70712,3667

<< Since open() returns an old-style handle, you can't use that handle with
any API that needs a HANDLE type. Note that MSC 6.0 for OS/2 contained a few
run-time APIs to open pipes and return file handles. The _pipe call opens a
pipe a returns an old-style read and write handle that you can then use with
the old-style run-time calls. The _popen API spawns a child process and
returns a FILE * handle which is one end of a pipe connected to the child's
stdout stream. I don't know if both of these calls will be available in the
run-time libraries for the compiler for NT, but they exist in the current .h
files; I'll check with our compiler people and see if these pipe APIs will be
available in the run-time libraries. >>

George, I've finally heard back that these run-time calls will be available.
Check them out with the next release you will be receiving shortly (if not
already). They are some very handy calls.

-Eric

#: 15843 S6/API-Base/Security
    26-Oct-92  22:41:16
Sb: UnpackDDElParam problems
Fm: Bruce Cowan 73650,32
To: all

The July release of NT made available the internal forms of the DDE message
lParam field, but the October one does not.  I don't want to use the internal
forms, but the UnpackDDElParam function is somewhat broken!  It has the
following problems that I have identified so far:

1. It will crash (access violation) if called to unpack the lParam received in
   a WM_DDE_ACK message which is an answer to a WM_DDE_INITIATE.  I already
   changed my code to not unpack such lParams, but I can change it back if you
   really need a better bug description.

2. It does not properly unpack the lParam for a WM_DDE_ACK which is an answer
   to a WM_DDE_EXECUTE (and it does require unpacking).  The values I get back
   are pure garbage!

BTW, it does correctly unpack the lParam for a WM_DDE_DATA message!

I am fairly certain my code is correct because I've snooped at the messages
using Spy and DDESpy and they look ok, and the other end of my DDE conversation
is Program Manager and it does what I tell it to (create a group and install
some icons in it).

Now, you may ask why I don't use DDEML.  The answer is simple - DDEML is quite
thoroughly broken in Windows 3.1 (it loses message replies at times - I reported
the problems way back during the Win 3.1 BETA and they were never fixed), and
I want to maintain common source code between by NT and Win 3.1 application.

I desperately need fix(es) here.  Thanks.

Bruce Cowan

#: 15745 S6/API-Base/Security
    25-Oct-92  06:25:54
Sb: Cross-Network Synchroniz
Fm: David S. Platt 73540,3430
To: All

Is it possible for an app on one machine to directly open a handle to a
synchronization object on another machine on the network, via OpenHandle( ),
and then wait on it via WaitForSingleObject ( ) ?  Sort of like:

Machine A
        CreateMutex (..., "SAMPLEMUTEX") ;

Machine B
        hSample = OpenHandle (... "\\Machinea\mutex\SAMPLEMUTEX"
        WaitForSingleObject (hSample) ;

If it is not possible to do it directly, is it possible to do it via Remote
Procedure Calls, say calling an RPC function that you know lives on the
machine where the mutex is, and can therefore access the object ?

Dave

#: 15894 S6/API-Base/Security
    27-Oct-92  15:18:29
Sb: #15745-Cross-Network Synchroniz
Fm: Bruce Ramsey/Microsoft 70324,2742
To: David S. Platt 73540,3430 (X)

Hi Dave -

>> Is it possible for an app on one machine to directly open a
  handle to a synchronization object on another machine on the
  network, via OpenHandle( ), and then wait on it via
  WaitForSingleObject ( ) ?  Sort of like:

  Machine A
          CreateMutex (..., "SAMPLEMUTEX") ;

  Machine B
          hSample = OpenHandle (... "\\Machinea\mutex\SAMPLEMUTEX"
          WaitForSingleObject (hSample) ;

No, you'll find (if you haven't already) that OpenEvent, OpenMutex
  and OpenSemaphore fail with error 161 ERROR_BAD_PATHNAME if
  there's any \ character in the synchronization object name

  Perhaps the ERROR_BAD_PATHNAME error name is a source of
    confusion as it might seem to imply that if only one could
    figure out the right syntax for specifying the pathname for
    the synchronization object on the remote machine, then this
    could be made to work.  There is, however, no such correct
    syntax

The purposes of Win32 synchronizatoin objects are to permit
  synchronization of activities of processes on the same machine.
  If synchronization of processes spanning multiple machines
  running Win32 apps is needed, RPC would be a natural way to do
  this, as mentioned below.  Needless to say, your design would
  want to take into account that synchronization using RPC across
  a network is going to take place at network speeds, not at RAM
  speeds

>> If it is not possible to do it directly, is it possible to do
  it via Remote Procedure Calls, say calling an RPC function that
  you know lives on the machine where the mutex is, and can
  therefore access the object?

Yes, this can be done (not directly, as mentioned above, but yes
  via RPC)

The procedure on the RPC server that is called by the RPC client
  code is not restricted in what it can do.  In other words, the
  RPC server code can do on the machine it is running on anything
  it could do if it were not packaged as RPC code

Bruce

#: 15744 S6/API-Base/Security
    25-Oct-92  06:25:51
Sb: Pipe Security
Fm: David S. Platt 73540,3430
To: All

Another question about security, on pipes this time.  Suppose user DAVE logs
in successfully on computer A and runs an app that creates a named pipe.
Suppose further that DAVE's app creates the pipe with security descriptors (an
ACL, with ACEs) permitting use by user GEORGE, who logs in on computer B, but
nobody else.  Three questions:

1.  If another user on the network, say MARTHA, tries to open the pipe, is her
request automatically rejected by the security manager ?

2.  When user GEORGE, whose access is allowed, tries to open the pipe, what
sort of checking is done by NT ?  Does GEORGE need a user ID and password on
machine A as well as machine B ?  Does GEORGE's request to open the pipe send
a password to machine A, to be checked there, or does NT assume that, since
GEORGE is a permitted user and has gotten machine B to let him log on, that he
must be legit ?

3.  If DAVE's app created the pipe without any security descriptor, would
anybody on the network be allowed to open it ?

Thanx

#: 15920 S6/API-Base/Security
    27-Oct-92  18:18:00
Sb: #15744-Pipe Security
Fm: Bruce Ramsey/Microsoft 70324,2742
To: David S. Platt 73540,3430 (X)

Hi Dave -

>> Another question about security, on pipes this time

Last question I saw from you on security was on Oct 10.  If I
  missed one please let me know.  Thanks :)

>> Suppose user DAVE logs in successfully on computer A and runs
  an app that creates a named pipe.  Suppose further that DAVE's
  app creates the pipe with security descriptors (an ACL, with
  ACEs) permitting use by user GEORGE, who logs in on computer B,
  but nobody else.  Three questions:

To clarify, let's assume DAVE logs onto Computer A locally, that
  is, using the keyboard.  GEORGE will be logging onto Computer A
  as a network user, and logging onto Computer B locally (let's
  assume all machines in this scenario are running Windows NT)

>> 1. If another user on the network, say MARTHA, tries to open
  the pipe, is her request automatically rejected by the security
  manager?

Yes, via the normal means, ie, searching the ACL on the pipe
  against an access token that represents MARTHA

However (see also below) if the MARTHA account is not permitted to
  logon as a network user to Computer A, MARTHA won't even get as
  far as checking the ACL on the pipe.  If MARTHA isn't permitted
  to access Computer A as a network user, when MARTHA attempts
  access to anything on Computer A over the network, a logon
  process on Computer A kicks in, tries to log MARTHA on, and
  since she's not allowed on as a network user, the logon process
  rejects her before even creating an access token to support
  MARTHA's activities on Computer A as a network user

>> 2. When user GEORGE, whose access is allowed, tries to open the
  pipe, what sort of checking is done by NT?  Does GEORGE need a
  user ID and password on machine A as well as machine B?  Does
  GEORGE's request to open the pipe send a password to machine A,
  to be checked there, or does NT assume that, since GEORGE is a
  permitted user and has gotten machine B to let him log on, that
  he must be legit?

Let's consider two cases:

- Where LAN Manager for Windows NT is in use.  Computers A and B

[More]

There is 1 Reply.

#: 15921 S6/API-Base/Security
    27-Oct-92  18:18:13
Sb: #15920-Pipe Security
Fm: Bruce Ramsey/Microsoft 70324,2742
To: Bruce Ramsey/Microsoft 70324,2742 (X)

[Continued]

  are both members of the same domain.  LAN Manager for Windows NT
  will be running in control of this domain, either on Computer A
  or B, or on some other computer running Windows NT in the same
  domain.  Let's call this the Domain Case

- Where LAN Manager for Windows NT is not in use.  Computers A and
  B are running as individual Windows NT machines, and aren't
  members of any domain.  Let's call this the No-Domain Case

There are other possible cases, such as A and B are each in a
  domain, but A and B are in different domains.  But let's just
  stick to the above two cases for now

In the Domain Case:  When GEORGE logs on locally to Computer B, he
  logs on as GEORGE-in-this-domain, because the domain controller
  controls the logon.  When GEORGE accesses Computer A over the
  network, Computer A runs a network logon process which goes to
  the domain controller at network logon time, and again GEORGE is
  identified (this time as a network user on Computer A) as
  GEORGE-in-this-domain

In both cases an access token is created to record the fact that
  it's GEORGE-in-this-domain, and a SID (Security ID) unique to
  GEORGE-in-this-domain goes into the access tokens

That SID is the key, because that same GEORGE-in-this-domain SID
  is also the same SID that was put into an ACE on the ACL
  associated with the named pipe that DAVE's app created on
  Computer A.  That is to say, it had better be the same SID.  It
  has to be, or else GEORGE-in-this-domain isn't really authorized
  on that ACL

So, in the Domain Case, no, GEORGE doesn't need an account and
  password on both computers, because he is defined in the domain,
  and both computers let the domain controller authenticate GEORGE

In the No-Domain Case:  Yes, GEORGE has to have an account on both
  Computers A and B.  When he logs onto Computer A as a network
  user, he will be asked for his password as defined on Computer
  A.  The SID that identifies GEORGE-on-Computer-B and the SID that
  identifies GEORGE-on-Computer-A are different

  As a side note, if you test this sort of thing, be sure to set

[More]

There is 1 Reply.

#: 15922 S6/API-Base/Security
    27-Oct-92  18:18:25
Sb: #15921-Pipe Security
Fm: Bruce Ramsey/Microsoft 70324,2742
To: Bruce Ramsey/Microsoft 70324,2742 (X)

[Continued]

    the GUEST account password to some value different from
    GEORGE's account, and make GEORGE not a member of GUESTs.
    Otherwise you'll see GEORGE logging on as GUEST, which can be
    confusing when expecting GEORGE's logon attempt to fail

In the No-Domain Case, GEORGE or somebody has admin work to do to
  keep the account name/password definitions in synch so people
  don't get confused and forget which spelling of which user
  account's password is valid on which computer.  And which users
  are defined to be part of which groups

This admin task is one of the main reasons why people would choose
  to install LAN Manager for Windows NT and make their Windows NT
  computers members of a domain:  have one place where
  users/passwords, and groups, are defined/maintained.  The more
  users/passwords, and groups, to be maintained, the greater the
  benefit to moving into use of domains

>> 3. If DAVE's app created the pipe without any security
  descriptor, would anybody on the network be allowed to open it?

Under most conditions, even if the pipe (any securable object for
  that matter) were created with an API call that didn't specify a
  Security Descriptor, a default security descriptor would be
  built and used by the system.  The rules for how this is done
  are in the October CD Win32 Api help file (Index search on
  Security Overview, then click on Securable Objects)

Under some conditions (see those rules just mentioned), no default
  DACL (Discretionary ACL) will be created as part of the default
  Security Descriptor.  This grants universal unconditional access
  to the object, but remember that the user (MARTHA in this
  scenario) has to be able to log on (either locally or over the
  network) to Computer A successfully before MARTHA will have a
  chance to touch any objects on Computer A

If MARTHA is not premitted to access anything on Computer A over
  the network, she will (of course) not be able to touch any pipes
  on Computer A

Bruce

#: 15933 S6/API-Base/Security
    27-Oct-92  18:42:56
Sb: Win NT Shutdown
Fm: Leon G Rollison 70421,1702
To: sysop (X)

I just installed the October release of Windows NT / NTSDK.

The shutdown sequence doesn't work.  After I press Ctrl-Alt-Del, get the
dialog box, and press S to shutdown, Windows NT goes through the shutdown
procedure to the extent of closing all applications and displaying the Windows
NT bitmap and then hangs there.

Can anyone tell me what is wrong??

#: 15944 S6/API-Base/Security
    27-Oct-92  23:06:50
Sb: WOW - Toolhelp support
Fm: Ray Duncan 72241,52
To: SYSOP (X)

The documentation for the Oct Beta release doesn't mention one of the most
important new WOW features - support for ToolHelp.DLL based WIN-16
applications!  I was quite astonished when I accidentally ran my little system
monitor utility for Windows 3.1 under NT and it actually took off and
displayed the module list, global heap, and so on. Even InterruptRegister()
works and allows you to trap GP faults!  It seems like we're not very far from
being able to do WIN16 app developemnt under Windows/NT after all.

The WOW code that emulates the ToolHelp functions for the window class list
may have a bug though.  A program which walks the window class list with
ClassFirst under Win 3.1 causes a GP fault in WIN/NT.

#: 15755 S6/API-Base/Security
    25-Oct-92  16:47:19
Sb: Shared sections
Fm: Kent Cedola - Kitware 72230,1451
To: SYSOP (X)

Is it possible to export a variable from a DLL that is in shared section?  Or
do I need a function that returns the address?

Kent

#: 15973 S6/API-Base/Security
    28-Oct-92  11:44:19
Sb: #15755-Shared sections
Fm: Bob Landau [Microsoft] 70744,21
To: Kent Cedola - Kitware 72230,1451 (X)

Kent,

To export a variable takes 3 steps

1) define a section which the data resides in and mark it as shared 2)
exported it in the def file 3) access it via indirection.

The first you probably know but for the benefit of others you must below is it

 1)  FOO.C

 ....
 // define data section - similar to segments in MS-DOS or OS/2

 #pragma data_seg("MYSECTION");

 /* ALL the shared data; this section will be marked as READ WRITE SHARED in
the DEF
  * file. Note this is a necessary but not sufficient step to exporting data.
  */

  int sharedInt = 1 /* data must be initialized */

 #pragma data_seg(".data")
 /* Put the rest of the data in the DGROUP
  */

 ...

 FOO.DEF

  ...
  SECTIONS
   .data READ WRITE
   MYSECTION READ WRITE SHARED

 2)  EXPORT sharedInt CONSTANT
  ...

 MYAPP.C
 ...
 /* Note we're accessing the variables by indirection. Furthermore the
CONSTANT keyword
  * above is necessary inorder for each process to get the address of the data
mapped
  * into each processes address space.
  */

 3) extern int *sharedInt;

 ....

 Microsoft Developer Support

 Bob Landau

#: 15887 S6/API-Base/Security
    27-Oct-92  13:26:33
Sb: #15635-ExitWindowsEx?
Fm: Bob Landau [Microsoft] 70744,21
To: Ralph Smith 76376,3150 (X)

Ralph,

The below code will generally work provided you've given yourself SHUTDOWN
priviledge this will normally be the case.

Microsoft Developer Support

Bob Landau


                if (!OpenProcessToken(GetCurrentProcess(),
                        TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, &hToken)) {
                    wsprintf ( buffer, "OpenProcessToken Error #%d",
GetLastError ());
                    MessageBox(hWnd, buffer, NULL, MB_OK);
                }
                /* Get the LUID for shutdown privilege */

                LookupPrivilegeValue(NULL, TEXT("SeShutdownPrivilege"),
                        &tkp.Privileges[0].Luid);

                tkp.PrivilegeCount = 1;  /* one privilege to set    */
                tkp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;

                /* Get shutdown privilege for this process. */

                if (!AdjustTokenPrivileges(hToken, FALSE, &tkp, 0,
                        (PTOKEN_PRIVILEGES)NULL, 0)) {
                    wsprintf ( buffer, "AdjustTokenPrivileges Error #%d",
GetLastError
 ());
                    MessageBox(hWnd, buffer, NULL, MB_OK);
                }
                /* Shut down the system, and force all applications closed. */

                 if ( !ExitWindowsEx( EWX_REBOOT, 0 )) {
                    wsprintf ( buffer, "Error ExitWindows Error #%d",
GetLastError ());
                    MessageBox(hWnd, buffer, NULL, MB_OK);
                }




There is 1 Reply.

#: 15992 S6/API-Base/Security
    28-Oct-92  15:30:59
Sb: #15887-ExitWindowsEx?
Fm: Ralph Smith 76376,3150
To: Bob Landau [Microsoft] 70744,21 (X)

Bob: thanks for the answer, and code too!  Much appreciated (especially since
I haven't gotten into the security stuff yet!).

#: 15923 S6/API-Base/Security
    27-Oct-92  18:18:29
Sb: #15714-File Name Associations
Fm: Bruce Ramsey/Microsoft 70324,2742
To: Marc Singer 72130,2546 (X)

Hi Andrew, David, and Marc - I'm looking into these issues for
  you.  I apologize for not already have more info for you

Bruce

#: 15998 S6/API-Base/Security
    28-Oct-92  15:58:03
Sb: #15714-File Name Associations
Fm: Bruce Ramsey/Microsoft 70324,2742
To: Marc Singer 72130,2546 (X)

Hi Andrew, David, and Marc -

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

The .3 extension is still the method on Windows NT

I can't say too much about it, but the object-oriented project
  that was discussed at the July 6-8 1992 PDC as Cairo will have
  an object oriented file system to better address this

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

Microsoft doesn't provide clearinghouse-type services such as
  lists of known extensions or extension reservations

Name-space collisions could become more of an issue as more and
  more apps for Windows are in use.  There are already some third
  party solutions that manage cases where the same extension is in
  use, giving a pop-up to the user letting them choose which app
  to start

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

On Windows NT the information on the .3 extension is in the
  registry database.  Extended attributes aren't used for this on
  FAT, NTFS or HPFS

If you make a file a_long_file_name.txt on an NTFS partition, then
  double-click that file in File Manager, Notepad is started

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

The .3 extension is still the method, so FAT floppies support this

Bruce

#: 15767 S6/API-Base/Security
    26-Oct-92  06:22:37
Sb: NT Mailslot Read
Fm: Mark A Skerencak 71214,262
To: Microsoft

I am having problems porting a unix inter process communication (IPC)
application. The unix application uses mailslots as I am attempting to do. The
test bed I am using is a single process that spawns two threads. Each thread
connects to a mailslot and continuously reads the mailslot to see if a message
have arrived.   I have set the timeout to MAILSLOT_WAIT_FOREVER. I do not want
the function ipc_msg_receive() to return until it has read a message. The code
below attempts to do that but it returns if the mailslot is empty.  Does the
call
SetMailslotInfo with a timeout of MAILSLOT_WAIT_FOREVER have any affect on the
ReadFile() call? Will the ReadFile() call return an error (fResult == 0) if
the
mailslot is empty (that is what it is doing now) even if the timeout was set
to
wait forever? Should I be using Named Pipes instead? Any help or sample
applications you could provide would be greatly appreciated.

#: 16003 S6/API-Base/Security
    28-Oct-92  16:20:07
Sb: #15767-NT Mailslot Read
Fm: David Taniguchi [MS] 72350,2054
To: Mark A Skerencak 71214,262

Hi Mark,
  Sorry for the delay.  I have reproduced your problem.   MAILSLOT_WAIT_
  FOREVER doesn't seem to work.  However, if you place
    SetMailslotInfo( hSlot, -1 );
  before the ReadFile(), it appears to wait forever (at least for several
  minutes -- it hasn't timed out yet :)
  Let me know if this doesn't work for you,
  Dave

#: 15888 S6/API-Base/Security
    27-Oct-92  14:15:36
Sb: Mailslot sample app's
Fm: Mark A Skerencak 71214,262
To: Microsoft

HELP!! (no doubt you've seen this before). Are there any sample applications
available that use mailslots? If one creates a mailslot via CreateMailslot,
sets the read timeout to MAILSLOT_WAIT_FOREVER via SetMailslotInfo, and posts
a read to the mailslot vai ReadFile,  will the read return immediately if the
mailslot is empty or is the read pending (i.e. the thread suspends) until a
message is written to the mailslot?  Thanx.

There is 1 Reply.

#: 16004 S6/API-Base/Security
    28-Oct-92  16:20:12
Sb: #15888-Mailslot sample app's
Fm: David Taniguchi [MS] 72350,2054
To: Mark A Skerencak 71214,262

Hi Mark,
  Try using SetMailslotInfo( hSlot, -1) before the ReadFile().  Let me
  know if you need more code.
  Thanks,
  Dave

#: 16006 S6/API-Base/Security
    28-Oct-92  16:30:39
Sb: Info on 'GetProcAddress'
Fm: Neil Goldstein 70632,3566
To: All

Forwarded from someone who doesn't have compuserve access:

I need info on GetProcAddress. We have created our own DLL and am not getting
the address back from a procedure point that we know is in the DLL, but we are
not getting an error either.

Please advise and thanks,

KenR ng

#: 15774 S6/API-Base/Security
    26-Oct-92  08:33:01
Sb: #15646-DLL: shared data
Fm: John Stoddard 72400,2551
To: Eric Sassaman/Microsoft 75430,411 (X)

Yup, that's just what I was doing - accessing the variable from an .EXE, and
resetting its value there... This whole area was very confusing, I just wrote
a bunch of test programs until I found out what worked and what didn't in my
environment. The key item I wouldn't have guessed on my own was that it was a
*pointer* to the item that was exported - any idea why this was done? It sure
has been the source of most of my problems in porting from OS/2!

John

#: 15977 S6/API-Base/Security
    28-Oct-92  12:08:52
Sb: #15774-DLL: shared data
Fm: Eric Sassaman/Microsoft 75430,411
To: John Stoddard 72400,2551

<< Yup, that's just what I was doing - accessing the variable from an .EXE,
and resetting its value there... This whole area was very confusing, I just
wrote a bunch of test programs until I found out what worked and what didn't
in my environment. The key item I wouldn't have guessed on my own was that it
was a *pointer* to the item that was exported - any idea why this was done? It
sure has been the source of most of my problems in porting from OS/2! >>

I had to take a peek at the sources to libcdll.dll to see how they were
exporting C run-time globals. I don't know why the variables appear as
pointers in the .exe... I assume there must have been a good reason for this
<g>!

I'll look into this and see if I can get any info on why in the world it was
done this way.

  Eric Sassaman
  Microsoft NT Support

#: 16018 S6/API-Base/Security
    28-Oct-92  19:13:32
Sb: #15774-DLL: shared data
Fm: Eric Sassaman/Microsoft 75430,411
To: John Stoddard 72400,2551

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

OOPS! Some kind soul here pointed out that my test program was invalid
(thanks, Robert! <g>). It turns out that you MUST specify CONSTANT or you
won't be able to *read* the DLL global, either. You need CONSTANT if it's
data, period.

  Eric Sassaman
  Microsoft NT Support

#: 16030 S6/API-Base/Security
    28-Oct-92  19:41:47
Sb: #15585-Event Time Stamps
Fm: Eric Sassaman/Microsoft 75430,411
To: dan white 70324,3147 (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. >>

There doesn't appear to be any way to set the times that the event logging
functions use. Can you be more specific about "what time stamp was used"?
Event log records (EVENTLOGRECORD) contains both the time that the record was
submitted and the time that the event-logging service received the record to
be written. Do you mean, which one of these times is shown on the screen in
the event viewer application?

What you might want to do is store a unique number with each event - put that
number in the lpvData parameter, then when you read them with ReadEventLog,
you can gain access to this number to match them up.

  Eric Sassaman
  Microsoft NT Support

#: 16031 S6/API-Base/Security
    28-Oct-92  19:55:21
Sb: #15562-RegQueryKeyValue
Fm: Eric Sassaman/Microsoft 75430,411
To: Marc Singer 72130,2546 (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? >>

No such beast as RegQueryKeyValue... do you mean RegQueryValue? The only LONG
is the return value, which is the same between both...

  Eric Sassaman
  Microsoft NT Support



There is 1 Reply.

#: 16044 S6/API-Base/Security
    29-Oct-92  01:58:05
Sb: #16031-RegQueryKeyValue
Fm: Marc Singer 72130,2546
To: Eric Sassaman/Microsoft 75430,411 (X)

The function is RegQueryValue, yes.  The parameter that is a problem is lpcb.
The type of pointer is different for NT than for Win 3.1.  One is signed and
one is unsigned.

Marc Singer -- Straylight Software

#: 16096 S6/API-Base/Security
    29-Oct-92  13:27:07
Sb: Exception hndling q's
Fm: Eric Sassaman/Microsoft 75430,411
To: David A. Solomon 71561,3603 (X)

<< 3. [This is more of a documention error] -- the EXCEPTION_DISPOSITION
structure is shown as the return value of the UnhandledExceptionFilter routine
(p.322 of Vol 2 of Win32 API book) -- however, this structure is not
documented in the data structures section of the Win32 API books. (I did find
it in a WINxxx.H file) -- just wanted to mention this documentation
oversight... >>

David, this is not a structure but rather an enumerated type. Possible values
are listed in the UnhandledExceptionFilter docs.

  Eric Sassaman
  Microsoft NT Support

#: 15788 S6/API-Base/Security
    26-Oct-92  11:54:21
Sb: Serial Port Handshakes
Fm: Howard Myers 76711,462
To: Microsoft

The release notes for the October Beta release discuss using software
handshaking for correct serial port operation.  It also suggests disabling
hardware handshaking.  As we develop serial communications apps., this has
very important implications to us.

First, is this suggestion just for the Beta release, or is this expected to be
"permanent"?

Second, is this just a suggestion for performance considerations or is there a
problem with the hardware handshaking?  Basically, why is this suggestion
being made?

If there is a problem with hardware handshaking, this is very bad news!  Many
of our customers depend on hardware handshaking. In many environments it is
faster (extra characters don't need to be transmitted).  Also, as hard as it
may be to believe, the whole world doesn't support software handshaking.

Thanks in advance!

#: 15965 S6/API-Base/Security
    28-Oct-92  10:04:37
Sb: #15788-Serial Port Handshakes
Fm: Don Cock 72520,1500
To: Howard Myers 76711,462 (X)

Howard,

     I too would like to express concern in not using hardware handshaking! I
read it ( it is in two locations ) as if you have problems, and in the second
instance always use xon/xoff.  I hope that this is just in the Oct. build and
not something that is permanent.

DonC


#: 16010 S6/API-Base/Security
    28-Oct-92  17:40:57
Sb: #15788-Serial Port Handshakes
Fm: Rik Logan 72350,3506
To: Howard Myers 76711,462 (X)

Howard,
  I think the Oct release notes were only meant for DOS communication
programs.  The problem comes from the fact that the DOS program access a 16450
type UART, and as such, the port must be virtualized.  Therefore, the less
hardware access you have to make, the better the performance.  This shouldn't
be true of native NT programs.

As an example, I have tapcis set up to access COM3, which under DOS is I/O
port 3E8h, and IRQ 4.  But in reality, my serial port #3 is at I/O port 188h,
IRQ 7.  So NT is able to emulate a serial port and redirect it to the proper
port.

Hope this helps,

Rik Logan

#: 16097 S6/API-Base/Security
    29-Oct-92  13:27:13
Sb: #15788-Serial Port Handshakes
Fm: Eric Sassaman/Microsoft 75430,411
To: Howard Myers 76711,462 (X)

<< The release notes for the October Beta release discuss using software
handshaking for correct serial port operation.  It also suggests disabling
hardware handshaking.  As we develop serial communications apps., this has
very important implications to us.

First, is this suggestion just for the Beta release, or is this expected to be
"permanent"?

Second, is this just a suggestion for performance considerations or is there a
problem with the hardware handshaking?  Basically, why is this suggestion
being made?

If there is a problem with hardware handshaking, this is very bad news!  Many
of our customers depend on hardware handshaking. In many environments it is
faster (extra characters don't need to be transmitted).  Also, as hard as it
may be to believe, the whole world doesn't support software handshaking.

Thanks in advance! >>

Howard, I'm not aware of the circumstances of this problem. I've sent out some
queries for more info and will get back to you as soon as I hear anything on
this.

  Eric Sassaman
  Microsoft NT Support

#: 16098 S6/API-Base/Security
    29-Oct-92  13:27:22
Sb: NTFS data attrib size
Fm: Eric Sassaman/Microsoft 75430,411
To: David A. Solomon 71561,3603 (X)

<< 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? >> _____

David, the NTFS file header contains general file info and a list of attribute
pairs. The attribute pair is an attribute header and either the attribute info
or a pointer to the attribute info. The data stream, alternate data stream,
security, EAs, etc. are all attributes. An NTFS header would look like:

file info | attribute pair | attribute pair | attribute pair...

If there are too many of these attribute pairs, then none of the attribute
info is stored in the header but rather pointers will be used instead to point
to the attribute info.

In a best-case scenario, if file data is the only attribute, then about 1K of
file data can be fit into the header as attribute information.

  Eric Sassaman
  Microsoft NT Support

#: 16117 S6/API-Base/Security
    29-Oct-92  13:59:39
Sb: signal, set/longjmp, ??
Fm: Eric Sassaman/Microsoft 75430,411
To: Noel J. Bergman/DEVTECH 76704,34 (X)

<< When the POSIX subsystem is released, will signals there be able to work in
the classic way, e.g., one can longjmp out of the ^C handler?  If so, what
kind of performance penalty will exist?

The bottom line, I guess, is how are signals mapped from the NT kernel into
the application domain by the API server? >>

Noel, I've finally gotten a copy of the exception handling whitepaper.
Unfotunately, it doesn't shed any light on how this will work under the POSIX
subsystem; it's primary audience is language implemetors. If you'd still like
to get a copy of this paper, send me a private message in this forum (no
email, please) with your address and I'll send you a copy.

Since the POSIX subsystem is still unreleased at this point, we have little to
no information on this, nor can we test this until later. More information on
the POSIX subsystem will be available when it is released.

  Eric Sassaman
  Microsoft NT Support

#: 15950 S6/API-Base/Security
    28-Oct-92  07:07:39
Sb: CreateWindow bug
Fm: George Eberhardt 70471,3647
To: sysop (X)


In the October 19 version.  It shows up if you:
 - specify size and origin
 - give the style as WS_MAXIMIZE
 - start the program from the PM.

The window comes up maximized, then is immediately resized to the given size
and location.  However, NT doesn't repaint the rest of the screen.  Also, if
the window is subsequently maximized the origin remains stationary and the
right side and bottom bleed off the screen.

This only happens if the program is started by double-clicking on the icon in
the PM.  If started from the prompt in the DOS box it behaves itself.





There is 1 Reply.

#: 16137 S6/API-Base/Security
    29-Oct-92  16:42:54
Sb: #15950-CreateWindow bug
Fm: David Taniguchi [MS] 72350,2054
To: George Eberhardt 70471,3647 (X)

Hi George,
  Thanks for the problem report.
  I couldn't find the upload but I did reproduce the behavior.  You can get
  around this by adding this to your WM_CREATE message:
    WINDOWPLACEMENT wp;

    GetWindowPlacement( hWnd, &wp);
    wp.showCmd = SW_SHOWMAXIMIZED;
    SetWindowPlacement( hWnd, &wp);

  I will make a report of the problem.
  Thanks,
  Dave

#: 15957 S6/API-Base/Security
    28-Oct-92  07:43:20
Sb: Determine User Privilege
Fm: David Van Camp 70740,366
To: Microsoft

Is there a way to find out if the currently loged on user has backup
privilege?  If so, how?

thanks,
steven de vos (posted for him by dvc)


There is 1 Reply.

#: 15989 S6/API-Base/Security
    28-Oct-92  14:06:16
Sb: #15957-Determine User Privilege
Fm: David Van Camp 70740,366
To: David Van Camp 70740,366

Here's some more info on what we are doing and the problem we are
experiencing...

We are attempting to check to determine if our app has backup privilege.  The
following code is a snipet of what we're doing.  However, this code *NEVER
FAILS* - even if we do not get access. why?

if (!OpenProcessToken( ProcessHandle, DesiredAccess, &TokenHandle)){
  error = GetLastError();
  printf( "Open process token failed, error = %d\n", error );
  return( -1 );
}
// Look up backup privilege
if (!LookupPrivilegeValue( NULL, "SeBackupPrivilege", &BackupValue )){
  error = GetLastError();
  printf( "Error %d: lookup privilege value failed.\n", error );
  return( -1 );
}
// Enable backup privilege for this process
NewState.PrivilegeCount           = 1;
NewState.Privileges[0].Luid       = BackupValue;
NewState.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;

if (!AdjustTokenPrivileges( TokenHandle, FALSE, &NewState, NULL, NULL, NULL)){
  error = GetLastError();
  printf( "Error %d: adjust backup token privilege failed.\n", error );
  return( -1 )
}

Mike Payne (posted by dvc)

There is 1 Reply.

#: 16163 S6/API-Base/Security
    29-Oct-92  21:08:20
Sb: #15989-Determine User Privilege
Fm: Robert Reichel [MS] 72360,3504
To: David Van Camp 70740,366

AdjustTokenPrivilege never fails, but will *always* set last error, even
to success, if necessary.  So when you call AdjustTokenPrivilege, throw
away the return value and call GetLastError() to see what happened.

This little tidbit didn't make it into the docs for this release.


#: 15841 S6/API-Base/Security
    26-Oct-92  22:37:29
Sb: WaitCommEvent weird
Fm: Bruce Cowan 73650,32
To: all

Overlapped (i.e. non-blocking) WaitCommEvent (on a real COM port) does not work
in a way that is consistent with other users of overlapped I/O.  For instance,
when one does an overlapped ReadFile, the lpNumberOfBytesRead dword is set to
0 at the time of the ReadFile call and is not referenced again by NT.  One gets
the actual transfer count by calling GetOverlappedResult.  However, in
WaitCommEvent, the lpdwEvtMask dword is filled in asynchronously by NT and the
GetOverlappedResult call only uselessly returns 4, the number of bytes in a
dword.  This is a bit non-intuitive to say the least.  This behavior should be
documented fully, since it is unusual for a dword result like this to be filled
in asynchronously.

Bruce Cowan

There is 1 Reply.

#: 16133 S6/API-Base/Security
    29-Oct-92  16:39:13
Sb: #15841-WaitCommEvent weird
Fm: Eric Sassaman/Microsoft 75430,411
To: Bruce Cowan 73650,32 (X)

<< Overlapped (i.e. non-blocking) WaitCommEvent (on a real COM port) does not
work in a way that is consistent with other users of overlapped I/O.  For
instance, when one does an overlapped ReadFile, the lpNumberOfBytesRead dword
is set to 0 at the time of the ReadFile call and is not referenced again by
NT.  One gets the actual transfer count by calling GetOverlappedResult.
However, in WaitCommEvent, the lpdwEvtMask dword is filled in asynchronously
by NT and the GetOverlappedResult call only uselessly returns 4, the number of
bytes in a dword.  This is a bit non-intuitive to say the least.  This
behavior should be documented fully, since it is unusual for a dword result
like this to be filled in asynchronously. >>

Bruce, the lpcbTransfer parameter to GetOverlappedResult is meaningless for a
WaitCommEvent operation. The documentation has been modified just recently to
refect this.

Concerning the lpdwEvtMask, this information is not available in the
OVERLAPPED structure, so the only alternative is to asynchronously update the
lpdwEvtMask. Just be sure not to check this mask until you've been signalled
and you'll be ok.

  Eric Sassaman
  Microsoft NT Support



There is 1 Reply.

#: 16185 S6/API-Base/Security
    30-Oct-92  08:36:54
Sb: #16133-WaitCommEvent weird
Fm: Bruce Cowan 73650,32
To: Eric Sassaman/Microsoft 75430,411 (X)

Thanks. I had figured out all that and really just wanted you folks to fix the
documentation so that no one else would waste time trying to figure out how it
works.

Bruce

#: 16198 S6/API-Base/Security
    30-Oct-92  10:52:57
Sb: GlobalSize fails on dlg
Fm: Len Gray 71630,1703
To: All

The code that I have been using to checksum a dialog is now failing under
Windows NT (Oct).  My code attempts to find, load, and lock a resource for
checksum as follows:

     if (hDlg = FindResource (hInstance, MAKEINTRESOURCE (IDD_DIALOG),
          RT_DIALOG))
       {
       if (hGlobalDlg = LoadResource (hInstance, hDlg))
         {
         lpDlgData = LockResource (hGlobalDlg);
         dwLength = GlobalSize (hGlobalDlg);
         .
         .
         .
         }
       }

This code works fine under Windows 3.1.  Under Windows NT, I seem to be
getting values back for my find, load, and lock calls.  The GlobalSize,
however, returns 0.

I've looked over the documentation looking for changes, but it seems that this
should still work.  I really don't know how to proceed from here.

Thanks for any and all help!

     Regards,
     Len

#: 16035 S6/API-Base/Security
    28-Oct-92  21:53:23
Sb: SetKeyboardState
Fm: John K Foderaro 71175,1610
To: all

 The SetKeyboardState function still doesn't work in the Oct release. I
submitted a sample program showing the problem in the July release and I
assume you still have it.
 I wrote a program (.exe and associated .dll) that interchanges the control
and caps lock keys.  It works fine in Windows 3.1.  The program (suitably
modified and compiled under Win32) had no effect in the July release (since
SetKeyboardState did nothing).  Compiling and running it in the Oct release
causes the NT system to freeze and the only option you have is to press the
reset button on the machine.  I can supply the program if you wish.

 My main goal is to find some way to interchange the control and caps lock
keys since the editor I use makes heavy use of the control key and without the
control key being in the 'usual' place it is hard to edit under NT. Since
SetKeyboardState (even if it worked) would probably not provide the global
mapping of caps to control under NT, I'd like to find another way of
interchanging the keys.   There must be a table in the keyboard driver that I
can modify to make this happen.  I'd appreciate a pointer to it. Thanks






There is 1 Reply.

#: 16210 S6/API-Base/Security
    30-Oct-92  13:07:00
Sb: #16035-SetKeyboardState
Fm: David Taniguchi [MS] 72350,2054
To: John K Foderaro 71175,1610

Hi John,
  I found your program and recompiled.
  You are correct.  The bug is still present in the Oct Release.  I submitted
  another bug report to development.  Hopefully, this will get fixed in the
  next release.

  Thanks,
  Dave

#: 16046 S6/API-Base/Security
    29-Oct-92  03:24:12
Sb: Portable File Commit
Fm: Robin 100025,604
To: ALL

I am writing an application which involves logging errors to disk. These
writes need to be commited ASAP so that the error situation doesn't kill the
machine before the error gets physically stored.

With WIN 3.1 I can commit writes by flushing Smartdrive using DOS3Call to call
Int 21h function 0dh. Is there a portable way that I can use both with Win 3.1
and WIN NT ? I would like to use the same code for both if possible, but using
a conditional compile otherwise.

Many thanks in advance for your help,

Robin Duerden.


There is 1 Reply.

#: 16211 S6/API-Base/Security
    30-Oct-92  13:07:06
Sb: #16046-Portable File Commit
Fm: David Taniguchi [MS] 72350,2054
To: Robin 100025,604

Hi Robin,
  >..Is there a portable way that I can use both with Win 3.1 and WIN NT ?
  I would like to use the same code for both if possible, but using a
  conditional compile otherwise.

  It looks like the only way you can have it portable between Win3.1 and
  Win NT is to use the C runtime fflush().  I believe using the C runtime
  stream I/O can slow the performance in Windows. (See Q72237)
  You might check out FlushFileBuffers() for NT.

  Hope this helps,
  Dave

#: 16215 S6/API-Base/Security
    30-Oct-92  13:17:10
Sb: Signal Anomaly
Fm: Andrew Potter 71075,614
To: all

The following program seems to act a little strange:

------------------- cut here ----------------------------------

#: 15753 S6/API-Base/Security
    25-Oct-92  14:55:11
Sb: #15707-DLL addresses
Fm: John Hall [MS SDE] 70750,2341
To: neil colvin 71650,3517

You use File mapping to create shared memory.
In the OS/2 Porting section, look up shrmem.zip, which is a DLL example that
provides shared memory to each process which attaches to it.  It also provides
something like 'named shared memory' ala OS/2, sets the virtual address attach
point to the same for each process (see docs) for those who need this, hands
out memory on page basis (4K) instead of the default 64K, and other stuff.

Questions about shrmem.zip to me.

#: 16135 S6/API-Base/Security
    29-Oct-92  16:39:26
Sb: #15682-DLL addresses
Fm: Eric Sassaman/Microsoft 75430,411
To: David Edge 75170,1461 (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? >>

The data addresses in the DLL will be identical (there would only be one set
of data addresses in the single code section), but remember that these are
virtual addresses, which map to different pages in different processes. Since
each process has a different page directory with different page directory
entries, they point to toally different areas of memory. Thus each DLL client
can have it's own copy of DLL global memory.

  Eric Sassaman
  Microsoft NT Support



There is 1 Reply.

#: 16220 S6/API-Base/Security
    30-Oct-92  14:24:28
Sb: #16135-DLL addresses
Fm: David Edge 75170,1461
To: Eric Sassaman/Microsoft 75430,411 (X)

Maybe I am missing something here, but please be patient with me for a moment.
Is it not true that the DLL's data space resides within the 2GB virtual
address space of the caller?  I understand that these are virtual addresses.
Here is a scenario: process 1 loads a DLL and the DLL gets its data space
mapped at virtual addresses 10000 -  11000.  Now, process 2 starts up and uses
virtual addresses 10000 -  20000, then loads the same DLL.  How will the DLL
access its data using those same virtual addresses when they are taken by the
caller?  Does the DLL have its address space outside of the address space of
the caller?  Perhaps this seems irrelevant but I am wanting to make extensive
use of DLLs from multiple applications and I want to understand what is going
on.  Thanks.

Dave.

#: 15789 S6/API-Base/Security
    26-Oct-92  11:55:12
Sb: GlobalCompact()
Fm: Howard Myers 76711,462
To: Microsoft

The GlobalCompact() function seems to have changed with the October Beta
release.  With the July release, it "seemed" to be returning the available
memory, just like the 3.x version does.  This made it very nice for
compatibility of code between the 2 environments.  Now it seems to return 0.
Thus 3.x code that looks at the return value fails.

I've patched my code, but just wanted to report this to you.

#: 16029 S6/API-Base/Security
    28-Oct-92  19:41:34
Sb: #15789-GlobalCompact()
Fm: Eric Sassaman/Microsoft 75430,411
To: Howard Myers 76711,462 (X)

<< The GlobalCompact() function seems to have changed with the October Beta
release.  With the July release, it "seemed" to be returning the available
memory, just like the 3.x version does.  This made it very nice for
compatibility of code between the 2 environments.  Now it seems to return 0.
Thus 3.x code that looks at the return value fails.

I've patched my code, but just wanted to report this to you. >>

The problem with making this call portable is that in a virtual memory system,
the return value of the old GlobalCompact doesn't make any sense. What kind of
number should it return under Win32? You have gobs of virtual memory
available... much better to use GlobalMemoryStatus to get a better idea of how
much of the various types of memory are available in the system. This is one
of those rare cases where something different should be done if you are
running on Win32, such as ignoring this return value.

  Eric Sassaman
  Microsoft NT Support



There are 2 Replies.

#: 16052 S6/API-Base/Security
    29-Oct-92  06:01:03
Sb: #16029-GlobalCompact()
Fm: Howard Myers 76711,462
To: Eric Sassaman/Microsoft 75430,411 (X)

I agree that using GlobalMemoryStatus() is a better approach -- and that is
what I am now using.  But if you want to help people port programs from 3.x to
NT, making these things as compatible as possible is a good idea.  Thus,
returning any one of the available types of memory would allow most apps. to
work.  I believe the July release did this.  Personally, if you aren't going
to be compatible with the old call, I wish you wouldn't put in a call that
does nothing at all.  At least with the call missing, flags get waved at link
time.  This way, I had 2 new bugs to tediously track down.

#: 16104 S6/API-Base/Security
    29-Oct-92  13:31:12
Sb: #16029-GlobalCompact()
Fm: Orin Eman 71102,705
To: Eric Sassaman/Microsoft 75430,411 (X)

Eric, this reply is ridiculous.  The same situation exists under Windows 3.0
and 3.1, there can be gobs of virtual memory available from DPMI, yet
GlobalCompact still does its thing and returns a value.

I'm sure GlobalCompact can use GlobalMemoryStatus itself and calculate a
reasonable number to return.

There is 1 Reply.

#: 16233 S6/API-Base/Security
    30-Oct-92  16:05:01
Sb: #16104-GlobalCompact()
Fm: David Taniguchi [MS] 72350,2054
To: Orin Eman 71102,705

Hi Orin,
  I would tend to agree with you.  I have submitted a suggestion to make
  GlobalCompact() return a non-zero value (as it did in the July Release).
  It does state in WinHelp that this is obsolete, but in the interest of
  portability, I can't see the harm of having it return a reasonable number
  (possibly based on GlobalMemoryStatus() as you mentioned.)

  Thanks,
  Dave

#: 15749 S6/API-Base/Security
    25-Oct-92  10:56:43
Sb: #15690-Redirected I/O & Pipes
Fm: Keith MacDonald 100041,235
To: Bob Landau [Microsoft] 70744,21 (X)

Bob,

Thanks for your reply.

I had already tried your suggestion and it mostly works!  If I
create a child process that writes to stdout and stderr and creates
another child that does the same, I get all their output through the
pipe as expected.

However, if the child is CL386, I can get the stdout or the stderr
of its children, but not both.

Any further suggestions would be very welcome.
Keith

#: 16134 S6/API-Base/Security
    29-Oct-92  16:39:19
Sb: #15749-Redirected I/O & Pipes
Fm: Eric Sassaman/Microsoft 75430,411
To: Keith MacDonald 100041,235

<< I had already tried your suggestion and it mostly works!  If I create a
child process that writes to stdout and stderr and creates another child that
does the same, I get all their output through the pipe as expected.

However, if the child is CL386, I can get the stdout or the stderr of its
children, but not both. >>

Keith, I'm running into some very strange problems when the child is cl386.exe
that I can't explain. It doesn't seem to like to have it's handles redirected!
I'm looking into this in more detail and will get back to you as soon as I can
get through these problems.

Let me know if you run into any problems with other .exe's besides cl386, and
I'll dig into the cl386.exe case.

  Eric Sassaman
  Microsoft NT Support

#: 16260 S6/API-Base/Security
    30-Oct-92  20:21:59
Sb: #15749-Redirected I/O & Pipes
Fm: Eric Sassaman/Microsoft 75430,411
To: Keith MacDonald 100041,235

<< I had already tried your suggestion and it mostly works!  If I create a
child process that writes to stdout and stderr and creates another child that
does the same, I get all their output through the pipe as expected.

However, if the child is CL386, I can get the stdout or the stderr of its
children, but not both. >>

Well, I've discovered the problem. cl386.exe appears to close stderr after it
prints out the copyright message. cl386.exe uses stderr to print this message
out so that if you redirect the output from the command line with the '>'
operator, your error files are not filled with copyright notices, since only
stdout is redirected in that case. It appears that cl386.exe closes the stderr
handle when it is done with it - this causes an ERROR_BROKEN_PIPE to be
returned to ReadFile. See, when cl386.exe starts up as your child process and
queries what the standard output and standard error file handles are, it will
receive the same handle number for both. When it closes standard error, it is
closing the one and only output handle it has, which closes down the anonymous
pipe to the parent - there are not two pipes, one for stdout and one for
stderr, but only one doing double-duty.

The workaround is to open two anonymous pipes, setting standard error to one
and standard output to the other, spawning the child, then starting another
thread to process one pipe while another thread processes the other pipe.
Unfortunately, you can't read from the standard output pipes in sequence; you
can't read from one pipe until ERROR_BROKEN_PIPE, then read from the other,
because the child may fill up the pipe you are not currently reading from and
block trying to write until there is more room in the pipe.

I would expect that in most cases child apps like this would never close one
of the standard output handles... so in most cases this will never bite. But
there's always that one rougue app... <grin>

My inherit sample in the \q_a directory will get bit by this as well. I'll
need to update this sample to show the proper way to avoid getting bit by

[More]

There is 1 Reply.

#: 16261 S6/API-Base/Security
    30-Oct-92  20:22:04
Sb: #16260-Redirected I/O & Pipes
Fm: Eric Sassaman/Microsoft 75430,411
To: Eric Sassaman/Microsoft 75430,411 (X)

[Continued]

this (especially since I show how to use inherit to spawn cl386.exe in the
help text!!)

Thanks for letting us know about this. Let me know if you run into any more
glitches.

  Eric Sassaman
  Microsoft NT Support




#: 15772 S7/Tools-Microsoft
    26-Oct-92  08:07:54
Sb: LINK386.EXE
Fm: dwight jones 71214,2705
To: anyone

I sent this mseeage once, but I'm not sure I did it right. If you already have
it, accept my apologies. I'm a brand new NT developer. I tried to compile a
sample program in the documentation. CL386 first.c was the command line. It
compiled, but on linking it responded with a message saying it could not
locate LINK386.EXE. I searched and could not find that program. Help! Thanks!


#: 15765 S7/Tools-Microsoft
    26-Oct-92  05:58:47
Sb: LINK386.exe
Fm: dwight jones 71214,2705
To: anybody

I am new to Windows NT. I tried to compile a sample program and got a message
"Unable to locate LINK386.EXE". I could not find LINK386.exe anywhere. Any
suggestions? Thanks.

There is 1 Reply.

#: 15785 S7/Tools-Microsoft
    26-Oct-92  11:50:56
Sb: #15765-LINK386.exe
Fm: Paul Tissue [Microsoft] 70744,24
To: dwight jones 71214,2705 (X)

Hello Dwight,

The CL386 compiler does not work the same way our C7 MS-DOS counterpart does;
you cannot compile and link in one pass using this compiler.  Please see the
Win32 SDK samples and create a makefile.  You can then use the NMAKE utility
in the same manner the samples do.

- Paul, Win32 SDK Developer Support

#: 15792 S7/Tools-Microsoft
    26-Oct-92  12:28:37
Sb: #15678-WINDBG (COMDEX/MS!)
Fm: Colin Stuart [Microsoft] 70744,25
To: Bill Carswell 74230,3710

Bill, I've been using WinDbg w/ the October Beta, and find it to be much more
robust. You should be getting this release soon, if not already.

Colin

#: 15756 S7/Tools-Microsoft
    25-Oct-92  17:15:39
Sb: Compile problems
Fm: Pete Grant 71172,3430
To: microsoft

Just got the Oct version of NT.  There seems to be some compiler differences
between the July and October releases.

The same exact program that compiled and ran just fine before now gives me
error messages that make no sense:

myfile.c(19) C2373: 'Sleep': redefinition; different type modifiers

There is no reference to any "Sleep" in any of my files.  I include
<windows.h> but didn't see Sleep there either.

I don't have time to reinstall the July version, but I threw the code at
Borland's compiler and it compiled without a beep.

Any ideas?




There is 1 Reply.

#: 15793 S7/Tools-Microsoft
    26-Oct-92  12:35:14
Sb: #15756-Compile problems
Fm: Doug Olson [Microsoft] 72350,2635
To: Pete Grant 71172,3430 (X)

Pete:

I have not encountered this problem yet.  I have a few questions.

Is WINDOWS.H the only file you are including?  Also, what is on line 19 of
myfile.c?

Thanks for the information, I am interested in what is causing this error.

 Sincerely,

 Doug Olson
 Microsoft Developer Support

#: 15802 S7/Tools-Microsoft
    26-Oct-92  14:02:56
Sb: #15618-COFF out of memory error
Fm: Doug Olson [Microsoft] 72350,2635
To: Brad Hines 76520,3314

Brad:

Thanks for reporting this problem.  For now, I suggest breaking the source
into two separate files.  This should correct the problem.

Is the a C or C++ module?

Please let me know if breaking up the file does not correct the problem.  I
will let you know if we find another work around.

 Sincerely,

 Doug Olson
 Microsoft Developer Support

#: 15784 S7/Tools-Microsoft
    26-Oct-92  11:50:50
Sb: Profiler
Fm: Paul Tissue [Microsoft] 70744,24
To: Howard Myers 76711,462 (X)

Hello Howard,

The October release does include the Win32 API profiler.  The needed binaries
are called APF32CVT.EXE and APF32DMP.EXE.  They are located in the
\MSTOOLS\BIN directory.  Please see the file \MSTOOLS\BIN\WAP.TXT for further
information.

- Paul, Win32 SDK Developer Support




There is 1 Reply.

#: 15799 S7/Tools-Microsoft
    26-Oct-92  13:58:21
Sb: #15784-Profiler
Fm: Howard Myers 76711,462
To: Paul Tissue [Microsoft] 70744,24 (X)

Thanks Paul.  I realized this after I'd posted the message. I tried to delete
it before it was retrieved, but apparently I was too slow (or you guys are
just super fast).

In any case, thanks for the help, even though my face is a little red.

I've already used the profiler and it's working great!

Thanks again!

There is 1 Reply.

#: 15807 S7/Tools-Microsoft
    26-Oct-92  14:53:20
Sb: #15799-Profiler
Fm: Paul Tissue [Microsoft] 70744,24
To: Howard Myers 76711,462

Hello Howard,

Good to hear things to found the profiler files!

FYI, we use a tool which continually downloads all new postings from
CompuServe and enters them into our database.  It appears that we downloaded
your posting before you deleted it.  In this situation, our database still
contains your original message without indication that it was deleted.  We
rarely use CompuServe in a interactive manner thus the fact you removed this
posting remained unknown to us.

- Paul, Win32 SDK Developer Support

#: 15805 S7/Tools-Microsoft
    26-Oct-92  14:14:00
Sb: test
Fm: Ted C. Ho 73310,150
To:  73310,150 (X)

this just a test

There is 1 Reply.

#: 15812 S7/Tools-Microsoft
    26-Oct-92  16:11:38
Sb: #15805-test
Fm: Paul Tissue [Microsoft] 70744,24
To: Ted C. Ho 73310,150

Hello Ted,

I just wanted to welcome you to the MSWIN32 forum and let you know that your
test posting in this forum worked.

- Paul, Win32 SDK Developer Support

#: 15813 S7/Tools-Microsoft
    26-Oct-92  16:27:27
Sb: #15578-Err Linking C & C++
Fm: Colin Stuart [Microsoft] 70744,25
To: Jim Young 72760,725

Jim, Make sure that you are correctly using the 'extern' and 'extern "C"'
keywords.  extern "C" prevents symbol decoration, and extern prevents
declaration of a symbol. In the case that you want to use an external,
undecorated symbol in a C++ file, you must put the external statements in an
extern "C" block. Below is an example that calls external variables and
functions between C and C++ files.  Enjoy! Colin ************ TEST.C
************* #include <stdio.h>

extern int xyz;             // expects external declarations extern void
Func1(void);    // " " " extern void Func2(void);    // " " "

void main(void) {
    xyz=123;
    printf("Within main.  xyz = %d\n",xyz);
    Func1();
    Func2(); }

*********** TEST1.CPP ************* #include <stdio.h>

extern "C"              // does not decorate fn or var names {
    int xyz;
    void xmain(void);
    void v(void); }

void v(void) {
    printf("inside v\n"); }

*********** TEST2.CPP ************* #include <stdio.h>

extern "C" {            // does not decorate fn or var names
    extern int xyz;        // expects external declarations
    void Func1(void);      // not external
    void Func2(void);      //  "    "
    extern void v(void);   // external function declaration }

void Func1(void) {
    printf("Inside Func1.  xyz = %d\n",xyz); }

void Func2(void) {
    v(); }

#: 15739 S7/Tools-Microsoft
    24-Oct-92  15:16:58
Sb: WINDBG Problem
Fm: Mark Patterson 76234,3364
To:  72350,2054 (X)

David,

I just got the October Beta of NT, and installed it.  I made the necessary
mods to the make files, and recompiled my project.  I was able to debug the
program under WINDBG, except for two problems.  The first is that I can't add
any watches - I highlight the variable, go to "add watch", and the variable is
not there.  I type it in, and it says it is undefined.  This, despite the fact
that I am currently at a break point in that module, so the vars should be
available.

The "?" command will not work in the command line either.

The second problem is that no local vars are displayed in the locals window.

My programs are C++, using MFC.  I compiled with debugging on: C opts: /Zd /Od
/D_DEBUG Link opts: -debug:full -debugtype:cv

The above are in addition to the regular options.

Any ideas?

Thanks, Mark.




There are 2 Replies.

#: 15742 S7/Tools-Microsoft
    25-Oct-92  04:42:40
Sb: #15739-WINDBG Problem
Fm: Kent Cedola - Kitware 72230,1451
To: Mark Patterson 76234,3364

Replace '-Zd' with '-Zi' in your compiles and then try WINDBG...

#: 15811 S7/Tools-Microsoft
    26-Oct-92  16:11:33
Sb: #15739-WINDBG Problem
Fm: Paul Tissue [Microsoft] 70744,24
To: Mark Patterson 76234,3364

Hello Mark,

Kent Cedola's suggestion of using the -Zi compiler flag should fix the
problem.

It is always wise to follow the makefiles that our Win32 SDK samples use. One
of the big motivating reasons why we created the NTWIN32.MAK master makefile
was to shield us from incremental compiler and linker changes that effected
our samples development effort.  I can definately say this helped alleviate
many difficulties for us and we hope you will find them useful also.

Let us know if you continue to have any difficulties building your
applications to take advantage of debugging information.

- Paul, Win32 SDK Developer Support

#: 15814 S7/Tools-Microsoft
    26-Oct-92  16:37:35
Sb: #15811-WINDBG Problem
Fm: Mark Patterson 76234,3364
To: Paul Tissue [Microsoft] 70744,24 (X)

Thanks for your suggestion.  Actually, I copied the WIN NT section from the
sample.mak file in the \mstools\mfc\samples directory, although I may have
missed a spot.  I'll check it out and let you know. Thanks for your help.
Mark.

#: 15816 S7/Tools-Microsoft
    26-Oct-92  16:58:57
Sb: Packed structure bug?
Fm: Doug Olson [Microsoft] 72350,2635
To: Bill Cohagan 74375,313 (X)

Bill:

You provided the following code in your message:

  #pragma pack(1)
  struct HEADER { BYTE htag:8; unsigned length:24;};
  #pragma pack()

I think what you are looking for is:

  #pragma pack(1)
  struct HEADER { unsigned htag:8, length:24;};
  #pragma pack()

This will make sizeof(HEADER) equal to 4 rather than 5. the slight difference
in syntax accounts for the extra byte.

 Sincerely,

 Doug Olson
 Microsoft Developer Support




There is 1 Reply.

#: 15839 S7/Tools-Microsoft
    26-Oct-92  22:35:15
Sb: #15816-Packed structure bug?
Fm: Bill Cohagan 74375,313
To: Doug Olson [Microsoft] 72350,2635 (X)

Doug-
  Thanks for figuring this one out.  I'll have to check the def of BYTE to
understand the distinction, but I'm sure it'll make sense if I RTFM.  Sorry to
use up your time on my error.

Bill

#: 15844 S7/Tools-Microsoft
    26-Oct-92  23:25:55
Sb: GetExceptionCode docs?
Fm: Bill Cohagan 74375,313
To: sysop (X)

I haven't found much documentation on the Exception codes returned by the
function, GetExceptionCode, and the related information returned by the
function, GetExceptionInformation.  I've searched the *.h files without
gleaning much additional info.  What I'm interested in doing is determining
(in an exception filter) whether the exception is either a read or write
memory protection fault.  If it is one of these then I'd like to figure out
the effective address which caused the exception.

Please point me to the necessary docs/code to figure this out if possible.
I've not yet received the October release, so let me know if the answers are
all to be found there.

BTW, does the October release include updated hardcopy docs or just a CDROM?

Thanks,
 Bill

#: 15845 S7/Tools-Microsoft
    26-Oct-92  23:46:24
Sb: GetExceptionCode foundit
Fm: Bill Cohagan 74375,313
To: sysop (X)

Never mind.....  I found the information on Exception codes and Exception
Information in the online help files.  Please disregard my request for help on
this one.

Bill

#: 15840 S7/Tools-Microsoft
    26-Oct-92  22:35:24
Sb: CVPACK breakpoint (?)
Fm: Bruce Cowan 73650,32
To: all

CVPACK still has problems in the October release.  When I compile my entire
program with -Zi, I get a breakpoint interrupt (0x80000003) in CVPACK at
0x6010a3d3.  When I limit the -Zi to the modules I need right now, everything
is fine.  My program is entirely C, no C++.  The source files are about 3.5M
bytes in total, and it is all linked into a single executable.  I presume
that since this is a hard-coded breakpoint, this is enough information to
give someone a clue as to what is going wrong.

My hardware configuration is IBM PS/2 model 95 486/33, 16M memory, no network,
XGA display.

Bruce Cowan

There is 1 Reply.

#: 15869 S7/Tools-Microsoft
    27-Oct-92  10:22:30
Sb: #15840-CVPACK breakpoint (?)
Fm: Doug Olson [Microsoft] 72350,2635
To: Bruce Cowan 73650,32 (X)

Bruce:

Thanks for the problem report.  I will report this to our CVPACK developer.  I
agree that a sample will most likely not be necessary.  If a work around is
found I will post the information here.

 Sincerely,

 Doug Olson
 Microsoft Developer Support

#: 15859 S7/Tools-Microsoft
    27-Oct-92  09:05:53
Sb: CVPACK
Fm: Manfred Dorsch 100015,155
To: sysop (X)

We need urgently help!
Hi,
I think CVPACK doesn't work very well. AFter compiling and linking the
following message occurs:
CVPACK:Fatal error CK1007: module Test.cxx
unknown type index 0x0007,
contact MS Product Support Services
CVPACK:error
can't exec COFF.EXE

For your information: We are developing a program in C++ under WindowNT. Our
program consists of 11 module.
If you have a new and better version of CVPACK, please put it to Compuserve as
soon as possible.
If you need more information you will contact us via compuserve.
Thank you

There is 1 Reply.

#: 15875 S7/Tools-Microsoft
    27-Oct-92  11:08:07
Sb: #15859-CVPACK
Fm: Doug Olson [Microsoft] 72350,2635
To: Manfred Dorsch 100015,155 (X)

Manfred:

Sorry to hear that you are having problems.  Have you received the October SDK
yet?  If so, please type CVPACK and verify that you are using version
1.318.01.

 Thanks,

 Doug Olson
 Microsoft Developer Support

#: 15893 S7/Tools-Microsoft
    27-Oct-92  15:16:55
Sb: #15698-Portable .EXE format
Fm: Colin Stuart [Microsoft] 70744,25
To: Samuel Feldman 70403,432 (X)

Samuel, I'll see what I can do. Colin

#: 15903 S7/Tools-Microsoft
    27-Oct-92  15:42:45
Sb: MFC Compiling
Fm: Doug Olson [Microsoft] 72350,2635
To: RAYMOND MILTON WOOD 76550,404

Raymond:

I have examined the information that you uploaded.  I found a couple minor
problems, but nothing that should cause the error you are receiving.  Below I
have listed some items to change and things to try, please let me know if any
of these correct the problem.

1. If you now have the October SDK, you will want to add the
C:\MSTOOLS\MFC\LIB directory to your LIB environment variable.  Adding this
path to your LIB path will allow the linker to find the MFC library.

2. Your temp and tmp environment variables are pointing to C:\TEMP.  Make sure
this directory exists and delete any files there.

3. On you include path, list C:\MSTOOLS\H before C:\MSTOOLS\MFC\INCLUDE.

4. If you just received the October SDK, install it and then give these
samples another try.

I hope that something here will help solve the problem. If not, please let me
know and we can continue working on this problem.

 Sincerely,

 Doug Olson
 Microsoft Developer Support

#: 15911 S7/Tools-Microsoft
    27-Oct-92  17:06:32
Sb: NMAKE and NMK fatal err.
Fm: Robert Eidson 70214,2115
To: sysop (X)

Dear Sysop:
   I'm having a heck of a time getting my system to work again now that I have
NT, Windows for Workgroups, Access, FoxPro and other assorted applications
installed.  I built a simple "Hello World" program (about5 lines of code), a
MAKEFILE (see below) and did a simple NMAKE. I got a message that the compiler
ran out of memory. I have 16meg on this system. I am, in this instance, using
C 6.0.  I have not attempted to use the C 7.0 I obtained from the Windows NT
system (not sure how I'd even do it). The MAKEFILE: styedit.obj : styedit.c
    cl  /c /AS /Od /Zi styedit.c

styedit.exe : styedit.obj
   /LINK /CO styedit.obj

When I type NMAKE I get the following failure:

cl  /c /AS /Od /Zi styedit.c styedit.c fatal error C1002: compiler is out of
heap space in Pass 2 NMAKE : fatal error U1077 : 'cl' : return code '2'

Where should I start in order to fix this mess?

#: 15919 S7/Tools-Microsoft
    27-Oct-92  18:16:01
Sb: Common dialog include
Fm: Colin Stuart [Microsoft] 70744,25
To: Marc Singer 72130,2546 (X)

Mark, I've reported this to development. Colin

#: 15927 S7/Tools-Microsoft
    27-Oct-92  18:22:57
Sb: #15586-Librarian error (COMDAT)
Fm: Doug Olson [Microsoft] 72350,2635
To: Brad Hines 76520,3314

Brad:

I believe this problem has been corrected in the October release.  Please give
it a try and let me know how it works for you.  (if you haven't received the
October SDK yet, it should be arriving very soon)

 Sincerely,

 Doug Olson
 Microsoft Developer Support

#: 15932 S7/Tools-Microsoft
    27-Oct-92  18:26:10
Sb: Bug in MSC C++
Fm: Greg Kochaniak 71461,631
To: Doug Olson [Microsoft] 72350,2635 (X)

Doug, thank you for your information on the bug with overloaded operators with
const parameters in the string class I reported previously. I hope you will be
able to fix it soon. I checked in October beta release of NT compiler, the bug
is still there. When you have a fix, plese do not wait until next NT release,
but post it on Compuserve so that we could have a better C++ compiler sooner.

Greg Kochaniak Ansoft Corp., Pittsburgh PA

#: 15851 S7/Tools-Microsoft
    27-Oct-92  06:01:52
Sb: MFC Classes
Fm: Jim Conger 73220,324
To:  72350,2635 (X)

I have one small problem when compiling using the October NT beta and the MFC
classes.  Normal compilation works fine, but I get the following error when I
attempt to create a pre-compiled header:

fatal error C1001:ITERNAL COMPILER ERROR
         (compiler file 'msc1.cpp', line 555)

The other compiler switches I'm using are:

-c -G3d -W3 -Di386=1 -D_NTWIN -D_WINDOWS -DWINVER=0x03a -YcAFXWIN.H

Any suggestions?

There is 1 Reply.

#: 15929 S7/Tools-Microsoft
    27-Oct-92  18:23:07
Sb: #15851-MFC Classes
Fm: Doug Olson [Microsoft] 72350,2635
To: Jim Conger 73220,324 (X)

Jim:

Thanks for reporting this problem, I will report it to our compiler
developers.  If a work around is found, I will let you know.

 Sincerely,

 Doug Olson
 Microsoft Developer Support




There is 1 Reply.

#: 15935 S7/Tools-Microsoft
    27-Oct-92  19:09:23
Sb: #15929-MFC Classes
Fm: Jim Conger 73220,324
To: Doug Olson [Microsoft] 72350,2635 (X)

Thanks for the quick response.  I have to add that I'm really impressed with
the progress on this beta.

#: 15758 S7/Tools-Microsoft
    25-Oct-92  21:22:29
Sb: DECLARE/IMPLEMENT_DYNAMI
Fm: Bill Cohagan 74375,313
To: sysop (X)

I have, with no success, been trying to build/access "Run-Time Class
Information" in an MFC application.  I think the problem (for me) is that the
documentation is not very clear on the requirements.  In particular, it
appears that in order to derive run-time class info for a derived class it
must already be available for its *direct* base class.  This becomes apparent
if one examines the macro definition for IMPLEMENT_DYNAMIC() in the file
afx.h. Since a base class, say FOO, must have a member classFOO in order for
derived classes to use IMPLEMENT_DYNAMIC, it must be that the base class has
its own DECLARE_DYNAMIC & IMPLEMENT_DYNAMIC.

I refer you to page 264 of _Class Libraries User's Guide_ where it says:

 > To use basic CObject functionality:
   o Use the normal C++ syntax to derive your class from COBject
     (or from a class derived from CObject).
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Later on, down the page, under "To add run-time class information:" it says:

 1.) Derive your class from CObject, as described in the previous section.
                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This seems to imply that runtime info needn't be retained all the way down the
chain; you apparently can include it just at the leaves of the derivation tree
-- but this isn't the case. I think the docs could use a bit of improvement
here.

Regards,
 Bill

#: 15928 S7/Tools-Microsoft
    27-Oct-92  18:23:02
Sb: #15758-DECLARE/IMPLEMENT_DYNAMI
Fm: Doug Olson [Microsoft] 72350,2635
To: Bill Cohagan 74375,313 (X)

Bill:

I will find out more information on this topic for you.

 Sincerely,

 Doug Olson
 Microsoft Developer Support

#: 15937 S7/Tools-Microsoft
    27-Oct-92  19:55:04
Sb: #15758-DECLARE/IMPLEMENT_DYNAMI
Fm: Doug Olson [Microsoft] 72350,2635
To: Bill Cohagan 74375,313 (X)

Bill:

>>I have, with no success, been trying to build/access "Run-Time Class
Information" in an MFC application.  I think the problem (for me) is that the
documentation is not very clear on the requirements.  In particular, it
appears that in order to derive run-time class info for a derived class it
must already be available for its *direct* base class.

This is correct. I agree that this should be made clearer in the
documentation. I have forwarded your message to our AFX group. Sorry for the
confusion.

 Sincerely,

 Doug Olson
 Microsoft Developer Support

#: 15810 S7/Tools-Microsoft
    26-Oct-92  15:42:52
Sb: C-Runtime DLL
Fm: Ted C. Ho 73310,150
To: All

Hi! In Windows NT release notes(Oct. 1992 release) p31, it states "If you need
to call C-Runtime functions in a DLL, then the entry point for the DLL must be
_CRT_INIT ...etc.

If I try to build a DLL do call the C-Runtime functions Instead of using
libc.lib or libcmt.lib, I am using C-Runtime DLL crtdll.dll.  Do I still need
to call _CRT_INIT at entry function?

Ted C. Ho

#: 15972 S7/Tools-Microsoft
    28-Oct-92  11:42:55
Sb: #15810-C-Runtime DLL
Fm: Colin Stuart [Microsoft] 70744,25
To: Ted C. Ho 73310,150 (X)

Ted, calling _CRT_INIT is unneccesary when dynamically linking your DLL with
CRTDLL.DLL.  Call the entry point only when statically linking with LIBC.LIB
or LIBCMT.LIB.

Colin

#: 15938 S7/Tools-Microsoft
    27-Oct-92  20:02:27
Sb: Too many drivers?
Fm: Robert Eidson 70214,2115
To: sysop (X)

I had a problem getting NMAKE.EXE, NMK.EXE and CV.EXE to run.  In my
config.sys I had the following drivers: DEVICE=C:\WINDOWS\HIMEM.SYS DEVICE =
C:\DOS\ANSI.SYS SHELL = C:\DOS\COMMAND.COM C:\ /P /E:1500
DEVICE=C:\WINDOWS\SMARTDRV.EXE /DOUBLE_BUFFER DEVICE=C:\DOS\RAMDRIVE.SYS 256
/I DEVICE=C:\WINDOWS\PROTMAN.DOS /I:C:\WINDOWS DEVICE=C:\WINDOWS\WORKGRP.SYS
DEVICE=C:\WINDOWS\SMCMAC.DOS DEVICE=C:\ASW410\ASPI4DOS.SYS
DEVICE=C:\ASW410\ASWCDNEC.SYS /D:ASPICD0

By removing the last 5 drivers I managed to get all three programs to run just
fine.  The problem:  I need these drivers to be available because they are for
Windows for Workgroup and Windows NT (the CDROM unit mostly).  The delema is
to keep the drivers and still be able to use C 6.0 until my Windows NT C 7.0
is capable of writing DOS code (as well as Win3.1 and NT). What solutions are
available to me to deal with this driver conjestion?

Bob Eidson





There is 1 Reply.

#: 15979 S7/Tools-Microsoft
    28-Oct-92  12:48:19
Sb: #15938-Too many drivers?
Fm: Paul Tissue [Microsoft] 70744,24
To: Robert Eidson 70214,2115 (X)

Hello Robert,

The AutoExec.Bat and Config.Sys files used under Windows NT are different then
the ones used under MS-DOS.  MS-DOS and DOSWOW expect these files to be named
as such thus these files are renamed appropriately by the Flexboot loader
depending on which OS you boot.  Under Windows NT AutoExec.### and Config.###
are the backed up MS-DOS versions of these files.  Under MS-DOS AutoExec.NT
and Config.NT are the backed up Windows NT versions of these files.  The table
below describes the file renaming that takes place:

 Windows NT         MS-DOS
 ------------       ------------
 AutoExec.Bat <---> AutoExec.NT
 AutoExec.NT  <--->  -deleted-
 AutoExec.### <---> AutoExec.Bat
 Config.Sys   <---> Config.NT
 Config.NT    <--->  -deleted-
 Config.###   <---> Config.Sys

Note: under Windows NT the .NT files soley act as placemarkers and are of zero
length.

Windows NT does not run MS-DOS device drivers.  Thus the MS-DOS drivers you
have loaded in the DOSWOW version of Config.Sys must be removed.  However, you
should leave them in the MS-DOS version of Config.Sys.  With the renaming of
these files that Flexboot takes care of, you will maintain separate version of
these essential startup files for both DOSWOW and MS-DOS.

I hope this helps to clearify how Windows NT handles the Config.Sys and
AutoExec.Bat files.

- Paul, Win32 SDK Developer Support

#: 15763 S7/Tools-Microsoft
    26-Oct-92  03:42:05
Sb: #15548-Porttool
Fm: Simon Moore 100014,1357
To: Cameron Ferroni [MS] 72360,2300 (X)

Another thought occured to me - would it be possible for you to provide a copy
of PORTTOOL built to run on 16 bit Windows? It would make life a little easier
for us.

Thanks

#: 15883 S7/Tools-Microsoft
    27-Oct-92  12:35:50
Sb: #15763-Porttool
Fm: Paul Tissue [Microsoft] 70744,24
To: Simon Moore 100014,1357 (X)

Hello Simon,

The October release of the Win32 SDK includes the source code to the PortTool.
Since it is a multi-threaded application it would take a bit of work to back
port it to Win16.  However it would not be too difficult to do so.  I expect
someone with the Win32 SDK will do such a port.  If this is the case I would
hope they would upload it to this forum so others may use this tool.  Are you
interested in doing such a port?

- Paul, Win32 SDK Developer Support




There is 1 Reply.

#: 15947 S7/Tools-Microsoft
    28-Oct-92  05:21:15
Sb: #15883-Porttool
Fm: Simon Moore 100014,1357
To: Paul Tissue [Microsoft] 70744,24 (X)

Well, I guess we might if its worth our while. Would it be easier to make it
work on WIN32S once that is available on pre-release,  presumably the
multithreading would still have to be removed?

(I'm looking forward to receiving the October NT release, once MS UK get their
distribution sorted out !)

Regards

-- Simon

There is 1 Reply.

#: 15986 S7/Tools-Microsoft
    28-Oct-92  13:43:06
Sb: #15947-Porttool
Fm: Paul Tissue [Microsoft] 70744,24
To: Simon Moore 100014,1357 (X)

Hello Simon,

I myself haven't taken a really good look at the code but from a quick scan of
it I'd say that back porting it to Win16 or just using the Win32s APIs would
require similar effort.  Once it was trimmed down by removing the
mulit-threaded features it would be quite easy to massage the code into a
common code base between Win16 and Win32s.  However one problem will be with
the 30,000 character limit of edit controls under Windows 3.x.  This may be
the most frustrating barrier to overcome.

- Paul, Win32 SDK Developer Support

#: 15876 S7/Tools-Microsoft
    27-Oct-92  11:22:53
Sb: Compiler error, Oct beta
Fm: Alan feuer 75500,3610
To: Mike Markley 72401,3051 (X)

Here is a VERY short program that generates an internal compiler error:

        #include <windows.h>

Here is how the compiler is run:

        cl386 -Di386 -Zge file.c

And here is the error:

        \mstools\h\winuser.h(111) : fatal error C1001: INTERNAL COMPILER ERROR
                (compiler file 'msc1.cpp', line 555)
                Contact Microsoft Product Support Services

Product support sent me here, but I'd prefer to get an answer on internet
([e-mail]).  This is a SERIOUS problem, but so obvious, there must be
something wrong with my installation. (BTW, this is with the October release.
Everything ran fine with the July release.)

alan feuer

There are 2 Replies.

#: 15901 S7/Tools-Microsoft
    27-Oct-92  15:25:06
Sb: #15876-Compiler error, Oct beta
Fm: Paul Tissue [Microsoft] 70744,24
To: Alan feuer 75500,3610 (X)

Hello Alan,

Thank you for reporting this problem.  I have verified it and reported this
bug to our developers.  As a work around discontinue using the -Zg switch and
create prototypes for your functions.

- Paul, Win32 SDK Developer Support

#: 15990 S7/Tools-Microsoft
    28-Oct-92  14:17:51
Sb: #15876-Compiler error, Oct beta
Fm: Mike Markley 72401,3051
To: Alan feuer 75500,3610 (X)

Is the only line in your file the #include <windows.h>? I have tried the same
thing on a Olivetti R4000 machine running the October build and did not see
the same problem. I don't have an Intel machine with October on it yet so I
can't try it there. If you have any #define statements preceeding the #include
try commenting them out and recompiling. Also check your environment The
October build from what I can tell is different then July. Also try just using
cl386 with no options. It may be an optimizer problem.

Mike Markley

#: 15842 S7/Tools-Microsoft
    26-Oct-92  22:38:08
Sb: slow link, windbg
Fm: Bruce Cowan 73650,32
To: all

I am very disappointed with the performance of the linker and the debugger in
the October release.  The debugger (Windbg) takes at least twice as long to
load the program to be debugged and the linker takes about 3 times as long to
link the program compared to the July release.  This is particularly
disappointing when the rest of the system is noticeably faster.

Perhaps a clue to the performance of the linker is that while it is busy, the
system is about 90% kernel state according to CPU Thermometer.  This is not
the situation with Windbg, it is mostly user state.

Oh, my machine is a 486/33.

Bruce Cowan

There is 1 Reply.

#: 15997 S7/Tools-Microsoft
    28-Oct-92  15:56:35
Sb: #15842-slow link, windbg
Fm: Colin Stuart [Microsoft] 70744,25
To: Bruce Cowan 73650,32 (X)

Bruce, I've gotten similar input from a few other people.  I do not yet know
what the causes or possible solutions are, but I will raise this as an issue
to development and post any new information as it becomes available.

Thanks for your posting, Colin

#: 15806 S7/Tools-Microsoft
    26-Oct-92  14:34:03
Sb: _CRT_INIT in DLL Failed
Fm: Ted C. Ho 73310,150
To: ALL

I have a little problem and need a big help !! I am using Windows NT SDK(Oct.
1992 beta release) C/C++ compiler to build a DLL with _CRT_INIT@12 as entry
function.  All modules in the DLL are compiled with D_MT and D_DLL and linked
successfully.

Whenever a program uses this DLL is failed right away @ _CRT_INIT with e calls
stack as follows:
   _RtlExAllocateHeap@12
   _calloc
   __mtinit
   ... and the error message I got from WinDbg is "First chance exception
c0000005 (Access Violation) occurred.  Thread stopped".

Do I miss anything to build a DLL correctly ? Any special compiling switch
that I should included ?????

P.S.  I don't use /Zp switch.

Anyone has a answer for me?   I will really appreciated.


Thanks   Ted

#: 16002 S7/Tools-Microsoft
    28-Oct-92  16:18:39
Sb: #15806-_CRT_INIT in DLL Failed
Fm: Colin Stuart [Microsoft] 70744,25
To: Ted C. Ho 73310,150 (X)

Ted, What C Runtime Library are you linking with?  LIBC.LIB, LIBCMT.LIB, or
dynamically, with CRTDLL.DLL?  If you are calling into CRTDLL.DLL, it is
unnecessary to call _CRT_INIT@12.

Colin

#: 15820 S7/Tools-Microsoft
    26-Oct-92  18:18:10
Sb: Trace into included .C
Fm: Ted C. Ho 73310,150
To: All

Hi! Is WinDbg program in Windows NT Oct. release able to trace into a source c
file included by another source c file?

I have a lot of modules are build by conditional compilation as follows: For
xxx.obj module - In xxx.c file:
   ...
   ...
   #if AAA
       #include <yyxxx.c>
   #else
       #include <zzxxx.c>
   #endif
   ...
   ... I never can trace into the module yyxxx.c or zzxxx.c with the source c
file.

Any special swith for compiliatio?, or just WinDbg could not do it.

Ted C. Ho

There is 1 Reply.

#: 16007 S7/Tools-Microsoft
    28-Oct-92  16:40:18
Sb: #15820-Trace into included .C
Fm: Colin Stuart [Microsoft] 70744,25
To: Ted C. Ho 73310,150 (X)

Ted,
 I'm getting some info on this. Please hold on.
 thanks,
 Colin

#: 16017 S7/Tools-Microsoft
    28-Oct-92  18:38:22
Sb: _CRT_INIT failure
Fm: Ted C. Ho 73310,150
To:  70744,25 (X)

Colin: I am using LIBCMT.LIB. It can be very easy to reproduce the problem by
some changes in compiling switch in the sample program comes with SDK under
\mstools\samples\select directory.

* Add addtional -D_MT switch when compiling select.c and demo.c * Use
libcmt.lib to build demo.exe and select.dll, and for building
  select.dll use -entry:_CRT_INIT@12.

Launch demo.exe program from WinDbg, then you should get "Access Violation"
error.

Hopefully, you can reproduce the problem.  Did I do something wrong? or It is
a bug in C-Runtime initialization function?

Ted

#: 16021 S7/Tools-Microsoft
    28-Oct-92  19:15:00
Sb: Help file search/index?
Fm: Bill Cohagan 74375,313
To: sysop (X)

I notice that the help file toolbar has been changed so that you now see
"Index" rather than "Search."  Unfortunately the help files themselves still
seem to refer to the "Search" button.  See. e.g., "MS Utility Warnings &
Errors" where instructions are given for looking up a particular error code.

Bill

There is 1 Reply.

#: 16036 S7/Tools-Microsoft
    28-Oct-92  22:10:30
Sb: #16021-Help file search/index?
Fm: Paul Tissue [Microsoft] 70744,24
To: Bill Cohagan 74375,313 (X)

Hello Bill,

Thank you for pointing out this change made to the search feature provided by
WinHelp.

We are replacing the [Search] feature with a full text searche (FTS) engine
instead of one that simply does index searches.  Thus we added the [Index]
button to take over the old search meaning.  Unfortunately the code to support
FTS did not make it into the October release.  We plan to have it ready by the
next release along with making the appropriate changes to references to these
search buttons in the help files.  Then you should see both the [Search] and
the [Index] buttons.

- Paul, Win32 SDK Developer Support

#: 16039 S7/Tools-Microsoft
    28-Oct-92  23:12:32
Sb: Custom Controls
Fm: Mark Gamber 76450,2754
To:  70744,25 (X)

Colin,  installed the October release, recompiled the custom controls and
   bingo...everything works fine with the Dialog Editor as evidenced by
   the uploads. (Third is on the way). Thanks a million!
      Mark Gamber

#: 15803 S7/Tools-Microsoft
    26-Oct-92  14:04:27
Sb: #15712-cvtres
Fm: Paul Tissue [Microsoft] 70744,24
To: Marc Singer 72130,2546

Hello Marc,

I have verified the problem with the sample dialog templates you posted.  I
will escalate this issue to our developers and ask for their input.  The
dialog templates you are using do not follow the same syntax that the Dialog
Editor creates.

If you make the following changes to the DLGINCLUDE line the problem goes
away:

 Old:
 ---
 === FOO1.DLG ===
 DLGINCLUDE RCDATA DISCARDABLE
 BEGIN
    "D:\\ELF\\TAXI\\DIALOG.H\0"
 END

 New:
 ---
 === FOO1.DLG ===
 1 DLGINCLUDE "D:\\ELF\\TAXI\\DIALOG.H\0"

I will get back with you on why the method you used did not work.

- Paul, Win32 SDK Developer Support

#: 15817 S7/Tools-Microsoft
    26-Oct-92  17:05:12
Sb: #15803-cvtres
Fm: Marc Singer 72130,2546
To: Paul Tissue [Microsoft] 70744,24 (X)

Paul,

You should know that my dialog templates were created with the Windows 3.1
dialog editor.  Is there an option in the 3.1 application that creates
templates using your prefered format?

Marc Singer -- Straylight Software




There are 2 Replies.

#: 15830 S7/Tools-Microsoft
    26-Oct-92  20:29:14
Sb: #15817-cvtres
Fm: Paul Tissue [Microsoft] 70744,24
To: Marc Singer 72130,2546 (X)

Hello Marc,

>> You should know that my dialog templates were created with the Windows 3.1
dialog editor.  <<

I kinda figured this was the case after I responded to you.  Anyway, Windows
16-bit source code compatability is one of our most important concerns around
here.  We have a general rule of thumb that if it works with Windows 3.x then
it should work for Win32 (within reasonable limitations of course <g>).

>> Is there an option in the 3.1 application that creates templates using your
prefered format? <<

Since the Win3.1 Dialog Editor was created before our changes were made to the
new Win32 DlgEdit, there is no setting which makes it comply to the "new"
format.  I am looking into the reason behind this change and suggest that we
still allow the resource compiling process to work with Win3.1 resource
scripts.  I'll let you know how things turn out.  Let me know if my suggestion
did not solve this problem.

- Paul, Win32 SDK Developer Support

#: 15881 S7/Tools-Microsoft
    27-Oct-92  12:35:35
Sb: #15817-cvtres
Fm: Paul Tissue [Microsoft] 70744,24
To: Marc Singer 72130,2546 (X)

Hello Marc,

It looks like the old Windows 3.x method of having mulitiple DLGINCLUDE RCDATA
resources was never "really supported" but RC.EXE never complained about it.
However, the CVTRES utility shipped with the October release is rather picky
on multiply defined resources.  Thus the new syntax is the only one to use.

You can also eliminate the DLGINCLUDE statments since the Dialog Editor is the
only thing that actually uses them.  The method of having multiple 1
DLGINCLUDE "DIALOH.H" statements is okay since this syntactical version of
DLGINCLUDE is handled correctly by RC.EXE.

Below is an excerpt from some email send by the developer of the Dialog Editor
covering the history of DLGINCLUDE and our plans for it.

Hope this helps!

- Paul, Win32 SDK Developer Support
------------------------------------------------------Dialog Resource Templates

For Win 3.1, the Dialog Editor needed a way to know what include file is
associated with a resource file that it is opening up.  Having the name of the
include file embedded in the resource file means that in most cases the editor
did not need to ask the user when they opened a resource file for editing
which include file went with it.

This was implemented as a resource of type RCDATA with the special name
"DLGINCLUDE".  This resource is placed into the res file, and contains the
name of the include file.  The dialog editor looks for this resource when it
loads a res file.  If it is found, then the include file is opened also.  If
not, the editor needs to prompt the user for which include file to open.

In some Win 3.1 build environments, the dialog editor was used to create
dialogs and they were placed in more than one .DLG file.  These different
DLG files were then included in one .RC file that was compiled with RC.
Because each .DLG file had this special resource, the result was a resource
file that had multiple copies of a RCDATA type resource with the same name,
"DLGINCLUDE".  The Win 3.1 resource compiler did not care about this.


[More]

There is 1 Reply.

#: 15882 S7/Tools-Microsoft
    27-Oct-92  12:35:45
Sb: #15881-cvtres
Fm: Paul Tissue [Microsoft] 70744,24
To: Paul Tissue [Microsoft] 70744,24 (X)

[Continued]

With NT, we were able to change it so that this resource had it's own resource
type.  It is no longer an RCDATA type resource with the special name
"DLGINCLUDE", but it is now a DLGINCLUDE "type" of resource, and the name does
not really matter.  The dialog editor in NT looks for a resource of the new
type DLGINCLUDE when it loads a resource file now.  This would have been nice
to do in the first place, but they were too close to shipping Win 3.1 to be
comfortable about changing RC.Exe, even though it was a small change.

Now in the last few months, there was a change that was made to CvtRes for
another problem that changed it so that it gave an error if there was a
resource found that had the same type, name and language as another resource
in the file.  In effect, it is now being stricter about the resources needing
to be unique that go into an executable.  Even though Win 3.1 allowed it,
having a duplicate resource was always bogus, because there was no guarantee
at run time which of the two or more resources would be returned by
LoadResource().

This means that some apps being ported to NT will give an error when their
resources are compiled, because they will have duplicate RCDATA type resources
with the same name ("DLGINCLUDE").  This error is correct.  The fix is very
easy, just delete all the DLGINCLUDE RCDATA type resource statements from all
the .DLG files and try it again.

Finally, because it does not make any sense to have even the new DLGINCLUDE
type resources in the executable at all, CvtRes will strip them out so that
they do not get linked into the exe.  Even if an application only has one
DLG file (and thus one old RCDATA type DLGINCLUDE resource), they should still
delete this old resource from their .DLG file, because it is no longer used
and does not need to take up space in the exe.




There is 1 Reply.

#: 15940 S7/Tools-Microsoft
    27-Oct-92  20:38:33
Sb: #15882-cvtres
Fm: Marc Singer 72130,2546
To: Paul Tissue [Microsoft] 70744,24 (X)

Paul,

I get that this is not mean to be supported, but can't you see your way clear
to support this bad behavior?  How about a switch for the new RC that can
delete these records automatically?  The trouble is that I use the .DLG files
in my normal make process and that I change them often during development.  It
seems to me that because this behavior came from the Windows 3.1 tool, you
need to permit the use of these older files without modification.

I would guess that you all assume that there are incompatibilities between the
two operating systems and that we developers must deal with them.  But
remember that I can write source files that compile in both environments
without too much trouble.  But this tool (dlgedit) creates templates that I
cannot use in Windows NT.  If the cvtres (or rc) developer refuses to support
the old templates, then I must edit the template by hand every time I make a
change.  Ouch.

After all, compatibility is absolute.  It is or it is not.

Marc Singer -- Straylight Software




There is 1 Reply.

#: 15985 S7/Tools-Microsoft
    28-Oct-92  13:43:00
Sb: #15940-cvtres
Fm: Paul Tissue [Microsoft] 70744,24
To: Marc Singer 72130,2546 (X)

Hello Marc,

>> How about a switch for the new RC that can delete these records
automatically? <<

I aggree that having the Win32 RC compiler (or CVTRES) strip the old
DLGINCLUDE RCDATA resources would be most helpful for application migration to
Win32.  I'll pass your suggestion along to our developers.

>> After all, compatibility is absolute.  It is or it is not. <<

I am not trying to stir up yet another endless debate but I must disagree with
this statement.  Compatibility is always a matter of degree.
 One can qualify the level of compatibility by stating that it is an absolute
or state that it maintains a certain _level_ of compatiblility.  We do not,
nor have we ever, claimed 100% compatiblity with Win16 sources. However we do
maintain that our level of source compatibility is very high with only minor
changes required, if any, in most cases.

IMO, requiring developers to remove the DLGINCLUDE RCDATA resource statements
(or use the Win32 version of DlgEdit which creates the correct DLGINCLUDE
statements) is asking for very little effort on the part of the developer who
wishes to produce an application that runs on an entirely new operation
system.  Hopefully we will provide a more acceptable solution to you liking in
a future release which removes these old RCDATA records.

Thanks again for you suggestion.

- Paul, Win32 SDK Developer Support




There is 1 Reply.

#: 16043 S7/Tools-Microsoft
    29-Oct-92  01:58:01
Sb: #15985-cvtres
Fm: Marc Singer 72130,2546
To: Paul Tissue [Microsoft] 70744,24 (X)

Though I think that a debate on semantics is inappropriate, I do think that it
is important to note the difference between C source level compatibility and
dialog editor resource compatibility.

I can write a source file that compiles under either system.  There are macros
to work around some of the compiler quirks, but these are completely backward
compatible.  No problem.

The output of your dialog editor tool is a different matter.  The C source
changes necessary for NT are (primarily) due to 32 bit widening and scrubbing
away sloppy programming practices.  But the dialog editor has no such
constraints.  The developer of that application made an arbitrary decision to
discard compatibilty for the sake of grace. This is a luxury that Microsoft
has thankfully denied itself which has benefited us developers tremendously.

So now, you have been driving your car for years and you take it to your
mechanic for a tune-up.  After getting the car back, she tells you that you
now have to kick the right rear tire each time before starting the car. Heck!
you say, but the car won't start without it. It turns out, she could have
replaced a ten cent part and you would never have had to do this. Sure, you
can still drive the car, but it takes just that much more effort each time you
start the engine.

%^)

Marc Singer -- Straylight Software

#: 15942 S7/Tools-Microsoft
    27-Oct-92  21:10:36
Sb:  TRACE option problems
Fm: Tushar Kale 71172,3210
To: Doug Olson 72350,2635 (X)

In October release of NT (just received today), I cann't get the
TRACE option in MFC programs to work properly. In earlier release, the
programs compiled with nmake DEBUG=1 would print the TRACE output
in the Command window of Windbg. In the new release, I just cann't
get it to work. I chacked the compiler and linker options and they
seem ok. Any suggestions ?

There is 1 Reply.

#: 15994 S7/Tools-Microsoft
    28-Oct-92  15:32:12
Sb: #15942- TRACE option problems
Fm: Doug Olson [Microsoft] 72350,2635
To: Tushar Kale 71172,3210 (X)

Tushar:

There is a file in the \MFC\SRC directory named AFX.INI that needs to be
copied to the \WINNT directory.  This file is necessary for TRACE to work
properly.

Please let me know if this does not correct the problem.

 Sincerely,

 Doug Olson
 Microsoft Developer Support




There is 1 Reply.

#: 16047 S7/Tools-Microsoft
    29-Oct-92  03:40:59
Sb: #15994- TRACE option problems
Fm: Tushar Kale 71172,3210
To: Doug Olson [Microsoft] 72350,2635 (X)

Doug:
Including AFX.INI enabled Trace printout in debugger. Thanks !!!

#: 16019 S7/Tools-Microsoft
    28-Oct-92  19:14:46
Sb: INTERNAL COMPILER ERROR
Fm: Bill Cohagan 74375,313
To: sysop (X)

I have just installed the October release and am attempting to compile/link my
application.  The last thing I did before installing the new release was to
recompile my app under the July release -- and had no problems.  This time I
get a fatal internal compiler error on one of my files when doing the nmake
with debug=1.  Doing a plain nmake goes all the way thru the link, but the
application hangs when I try to run it.

Anyway, following is the message I get when trying to compile in debug mode:
 =============================================cut here======================
  Microsoft (R) Program Maintenance Utility   Version 1.12.0013
  Copyright (c) Microsoft Corp 1988-90. All rights reserved.

          cl386 /c /G3d /W3 /Zi /Od /D_DEBUG /D_NTWIN /D_WINDOWS
/DWINVER=0x030a /
  Di386=1 /Yuscheme32.h binload.cpp
  Microsoft (R) C Optimizing Compiler Version 0.00.033
  Copyright (c) Microsoft Corp 1984-1992. All rights reserved.

  binload.cpp
  Compiler error (assertion): file @(#)emit.c:1.20, line 442 source=174
  Command line error D2030 : INTERNAL COMPILER ERROR in
'C:\MSTOOLS\bin\c23232.exe
  '
                  Contact Microsoft Product Support Services
  NMAKE : fatal error U1077: 'C:\winnt\system\cmd.exe' : return code '2'
  Stop.
 =================================================cut here=================

Let me know if you need additional info.

Thanks,
 Bill

#: 16058 S7/Tools-Microsoft
    29-Oct-92  07:35:19
Sb: INTERNAL COMPILER ERROR
Fm: George Eberhardt 70471,3647
To: sysop (X)


Generated by this construction:

 switch(ptr_to_object->method_ret'ing_ptr_to_class()->method_ret'ing_int){

The omission of parens for the second method is my programming error. CL386 is
dated September 29, and relevent switches include -G3 -W3 -Zi -Od.

#: 15804 S7/Tools-Microsoft
    26-Oct-92  14:04:32
Sb: #15628-WinDbg
Fm: Paul Tissue [Microsoft] 70744,24
To: Howard Myers 76711,462

Hello Howard,

Did you try using the -Od compiler switch to turn off code optimization?

FYI, if you always check how we build are SDK samples you will have less
trouble building or debugging your own applications.  Please let me know if
this does not solve the problem.  Also include how you are buildings your
samples (makefile, code snippets, etc.).

- Paul, Win32 SDK Developer Support

#: 15853 S7/Tools-Microsoft
    27-Oct-92  07:23:24
Sb: #15804-WinDbg
Fm: Howard Myers 76711,462
To: Paul Tissue [Microsoft] 70744,24 (X)

Paul,

For compile, I use the following options: -DWIN32 -c -G3d -W3 -Di386=1 -Zi -Od
For linking: -subsystem:windows -entry:WinMainCRTStartup -debug:full
-debugtype:cv

My build mechanism was taken from your samples.  It has evolved somewhat since
I must make our build also compatible with 3.1.  Thus, it may not be
identical, but it meets our needs quite well.  I've only found one file that
exhibits this problem so far (although there are many I haven't had to debug
yet), so it seems unlikely that it's an options problem.

If uploading the .OBJ or the particular source file would help, this is
possible.  Also, the .EXE could be uploaded, but it's about 2.5M.  Providing
all of the source to build the project is probably not possible, however.

Any other ideas? Thanks!

There is 1 Reply.

#: 15884 S7/Tools-Microsoft
    27-Oct-92  12:58:33
Sb: #15853-WinDbg
Fm: Paul Tissue [Microsoft] 70744,24
To: Howard Myers 76711,462 (X)

Hello Howard,

We have made a few changes with the October release in regard to
compiling/linking and the calling convention.  The -Gd switch selects the C
run-time calling convention as the default.  However we have changed to
STDCALL (Standard Call).  Thus, you should remove the -Gd option and accept
the default (STDCALL) used by the compiler.

Please give this a try and let me know if you have any problems.

Also, since it is only one file that behaves this way I suspect there is
something "special" about it.  Is this single C file used to create a single
OBJ file?  Is this file one of many C files used to create a single OBJ file?
Is there something else a bit out of the ordinary about this particular file
that may be suspect of causing such a problem?  (FYI, source code that is

#: 15955 S7/Tools-Microsoft
    28-Oct-92  07:32:04
Sb: #15884-WinDbg
Fm: Howard Myers 76711,462
To: Paul Tissue [Microsoft] 70744,24 (X)

Paul,

I removed the -Gd switch, with no change.  As far as I can tell, this
particular source file is no different than the rest.  It generates 1 .OBJ, is
not as large as some other files that are working (.OBJ and .C), is bigger
than others, the code exists in the file itself -- it is not #include'd,...

The same is true for the file that WinDbg won't load at all -- to the best of
my knowledge, there is nothing special about it.

Your ideas have been good so far, just haven't found the problem.  Got any
more? Want me to upload the .C and .OBJ file for analysis?

Thanks!

There are 2 Replies.

#: 15987 S7/Tools-Microsoft
    28-Oct-92  13:43:11
Sb: #15955-WinDbg
Fm: Paul Tissue [Microsoft] 70744,24
To: Howard Myers 76711,462 (X)

Hi Howard,

I have run out of ideas on this one.  If you could create a simple test driver
app for this OBJ file and upload it along with the OBJ and C file (and all
essential files to built the test case) then I'll take a look at them.  I can
understand the frustrations of not being able to debug your code.  I've been
there a few times myself.  Hopefully I can find something that will get you
back on the debugging track.

- Paul, Win32 SDK Developer Support

#: 16061 S7/Tools-Microsoft
    29-Oct-92  08:07:35
Sb: #15955-WinDbg
Fm: Bruce Cowan 73650,32
To: Howard Myers 76711,462 (X)

PMJI, but I have a very similar problem: Windbg doesn't like one (at least) of
my C source files. It refuses to load it either automatically (trace into it)
or via File Open. I can't see anything strange about the file at all. It is
compiled the same as all my other source files (-c -G3 -W3 -Di386=1 -DWIN32 -Zi
-Od -DDEBUG).

Bruce Cowan

#: 16065 S7/Tools-Microsoft
    29-Oct-92  08:34:39
Sb: Compiler Hangup
Fm: David M. Smith 76337,3225
To: Doug Olson [Microsoft] 72350,2635 (X)

Doug:

We have a large C source file (335kb) that the compiler chews on for a while
and then seems to just hangup. The process is still there but nothing seem to
be going on. The code is machine generated and is mostly static array
initializations.  Is there any thing I can do to find out what is happening
when the compiler goes to sleep?

I know that we could split this file up into smaller units but this file will
also work with many other compilers.

Thank for any help. Dave Smith

#: 16063 S7/Tools-Microsoft
    29-Oct-92  08:08:40
Sb: Windbg problems
Fm: Bruce Cowan 73650,32
To: Sysop (X)

I have a few Windbg bugs which should be mentioned:

1. There are times when the Locals window shows completely the wrong values
   for the local variables. I have one function in which it always happens the
   second time I hit a breakpoint in the function. Closing and re-opening the
   locals window gets the correct values displayed. (This one led me on a real
   merry chase before I figured out it was the debugger.)

2. Frequently on exit, Windbg will crash at 0x60107e2a reading memory at
   0x00000010. This only happens when the program being debugged has exited
   normally before Windbg is stopped. Trying to debug it doesn't work so I
   can't give more info.

3. Sometimes, Windbg leaves the .EXE file locked in some way after exit, so
   I can't re-link the program.  To get rid of the lock I log off and back on.
   Is there a better way?  This is not very repeatable: 4 times in 3 long days.

October release, PS/2 95, 16M memory.

Bruce Cowan

There are 2 Replies.

#: 16066 S7/Tools-Microsoft
    29-Oct-92  08:38:42
Sb: #16063-Windbg problems
Fm: Carl H Bache [PS Norway] 100010,2257
To: Bruce Cowan 73650,32 (X)

Bruce,

that lock on the EXE-file sounds familiar.  I've had that one, too.

Dag Baardsen

#: 16071 S7/Tools-Microsoft
    29-Oct-92  09:02:48
Sb: #16063-Windbg problems
Fm: Ray Duncan 72241,52
To: Bruce Cowan 73650,32 (X)

I suspect the "locked EXE" file problem is buried deeper in the system.  I
have also seen this in other situations - for example if you fire up PVIEW and
inspect the memory usage of some active process, the LINKer will then refuse
to write that EXE file.

#: 16073 S7/Tools-Microsoft
    29-Oct-92  09:19:22
Sb: Compiler Bug
Fm: David J. Plunkett 71163,2122
To: Microsoft

Here's another compiler bug.  The values of g and h are zero
at the print statement.  What'd you guys do to the compiler
since July?

#: 16076 S7/Tools-Microsoft
    29-Oct-92  10:39:42
Sb: WinDbg won't load source
Fm: Brent Ingraham (M&M) 70550,2303
To: SYSOP (X)

  Am having trouble with WinDbg recognizing all of my source files.  I've
  got approximately 50 .CPP files in this project and it will not load one
  of them.  I thought maybe because it was the first item in the file open
  listbox (ACTIVMAN.CPP), so I padded a dummy .CPP in the file with
  (AADUMMY.CPP).  This didn't solve the problem either.  I then TRACED INTO
  the program and I can't even toggle from dissassembly mode to source mode
  on the object code when it's in scope.  I know this module was compiled
  with debugging info!  I also can load other module source of objects with
  larger amounts of source and larger .OBJ size!  The .EXE with debug info
  is right at 1meg and the object in question is ~800 lines source with a
  debug .OBJ size of 143K.  What's up???



  Also, on a side note, I got the following error out of WinDbg the other
  day.  Seems like a string overrun....

  WinDbg Error:  Assertion Failed Line 338
                 D:\nt\private\windbg\windbg\util.c
                 Condition: LoadString( hInst, wErrorFormat, (LPSTR)
                 szErrorFormat, MAX_MSG_TXT);

  This error did crash NT and wiped out my Administrator Account (the active
  account) and I had to resort to the emergency disk to fix NT!

#: 16080 S7/Tools-Microsoft
    29-Oct-92  10:47:55
Sb: Windbg Remote Debugging
Fm: dan white 70324,3147
To: sysop (X)

Where do I find out how to use Windbg for remote debugging?

               Thanks, Dan




There is 1 Reply.

#: 16084 S7/Tools-Microsoft
    29-Oct-92  11:05:33
Sb: #16080-Windbg Remote Debugging
Fm: Paul Tissue [Microsoft] 70744,24
To: dan white 70324,3147 (X)

Hello Dan,

The file \MSTOOLS\README.TXT, which is included in the "Win32 Software
Development" group, contains the instructions necessary to setup remote
debugging with WinDebug.  You will find the instruction near the botton of
this file.  If you have any questions or trouble getting to work then let us
know.

- Paul, Win32 SDK Developer Support

#: 15934 S7/Tools-Microsoft
    27-Oct-92  18:43:53
Sb: Debugging POSIX
Fm: Joel Goldberger 76264,2510
To: ALL

I have tried both the sample POSIX app (PSXARC) and a "hello world" style
program and have been unable to get WINDBG to load symbols.  Is there a
missing switch in ntwin32.mak or is symbolic debugging not available with the
posix subsystem ?

Thanks in advance for the help ! Joel Goldberger

There is 1 Reply.

#: 16101 S7/Tools-Microsoft
    29-Oct-92  13:30:28
Sb: #15934-Debugging POSIX
Fm: Colin Stuart [Microsoft] 70744,25
To: Joel Goldberger 76264,2510 (X)

 Joel, Unfortunatly, WinDbg does not currently support symbolic debugging of
Posix apps.  I will raise this as an issue to development, and post any new
information as it becomes available

 Thanks,
 Colin

#: 15895 S7/Tools-Microsoft
    27-Oct-92  15:19:23
Sb: C Runtime Bug
Fm: Kevin Quinn 75430,255
To: Microsoft

Lo all ye at Microsoft: I have a bug encountered.

The issue is floating point to integer conversion.

A statement of the following form, when executed as a part of a _large_
program, causes the integer 'value' to be incorrectly evaluated as 0.

int value = 64;
value +=
      (float * 0) * int +
      (float * 0) * int;

When run as a standalone test program, it works as expected.

Pre-July this *worked*.  It fails in the July release; once I've a few
thousand more files compiled under OctoberFest, I'll try again.  (picky
little compiler this time 'round, mates!).

FYI, the offending call is _ftol; the failing instruction is
'fistp qword ptr [epb-0xc]'.

There does exist a workaround: decomposing the statement, and using
intermediate variables explicitly cast.  However, we use *lots* of mixed
float/int stuff, and lord knows where this is gonna bite us again.


Kevin Quinn
Desktop Systems
Ingres

There is 1 Reply.

#: 16102 S7/Tools-Microsoft
    29-Oct-92  13:30:30
Sb: #15895-C Runtime Bug
Fm: Colin Stuart [Microsoft] 70744,25
To: Kevin Quinn 75430,255

Kevin, Please do see if you can reproduce this error on the October build.  If
so, let me know, and I will contact development immediately.

 Thank you,
 Colin

#: 15815 S7/Tools-Microsoft
    26-Oct-92  16:48:00
Sb: Another Compiler BUG
Fm: Orin Eman 71102,705
To: sysop (X)

The following does not compile with the October SDK:

    const int **ppi;

    ppi = new const int *[10];

It claims that const/volatile objects cannot be allocated.

This code DOES NOT allocate a const/volatile object, it allocates an array of
pointers to const objects.

The compiler is clearly wrong here.

There are 2 Replies.

#: 15873 S7/Tools-Microsoft
    27-Oct-92  11:07:59
Sb: #15815-Another Compiler BUG
Fm: Doug Olson [Microsoft] 72350,2635
To: Orin Eman 71102,705 (X)

Orin:

Thanks again, like before I have someone looking into this (one of our
language developers) and I will get back with soon.

 Sincerely,

 Doug Olson
 Microsoft Developer Support

#: 16112 S7/Tools-Microsoft
    29-Oct-92  13:35:53
Sb: #15815-Another Compiler BUG
Fm: Doug Olson [Microsoft] 72350,2635
To: Orin Eman 71102,705 (X)

Orin:

One of our compiler developer looked at this and has confirmed that it is a
bug.  I'm sure you already knew that, but I wanted to let you know the status.
There is not a work around besides removing the const keyword at this point.

 Thanks,

 Doug Olson
 Microsoft Developer Support

#: 15808 S7/Tools-Microsoft
    26-Oct-92  14:56:06
Sb: Critical compiler BUG
Fm: Orin Eman 71102,705
To: sysop sysop (X)

The following worked with the July release of NT.  It works with current
releases of competing compilers under Windows and OS/2.  It now fails with the
October release of NT:

void main() {
    typedef char *PCHAR;
    typedef void *PVOID;
    PVOID pv;
    PCHAR *pc;

    pc = PCHAR(pv);    // works
    pv = PVOID(pc);    // works
    pv = PVOID( PCHAR(pv) );    // fails
    pv = PVOID( PCHAR(pv) + 10 );    // fails }

According to the Annotatated C++ Reference Manual, section 5.2.3, "a
simple-type-name followed by a parenthesized expression-list constructs a
value of the specified type given the expression list. If the expression list
specifies more than single value, the type must be a class..."

According to sections 7.1.3 and 7.1.6, any typedef'd type is a
simple-type-name.


This bug is severely affecting our development schedule.

#: 15872 S7/Tools-Microsoft
    27-Oct-92  11:07:54
Sb: #15808-Critical compiler BUG
Fm: Doug Olson [Microsoft] 72350,2635
To: Orin Eman 71102,705 (X)

Orin:

Thanks for reporting this problem with the compiler.  I have someone looking
into it and will get back with you as soon as possible.

 Sincerely,

 Doug Olson
 Microsoft Developer Support

#: 16113 S7/Tools-Microsoft
    29-Oct-92  13:35:59
Sb: #15808-Critical compiler BUG
Fm: Doug Olson [Microsoft] 72350,2635
To: Orin Eman 71102,705 (X)

Orin:

Thanks for waiting.  Development informed me that this is a bug that they are
currently looking at.  Unfortunately, the only work around for now is to use
C-style casts such as PVOID((PCHAR)(pv)) instead of PVOID(PCHAR(pv)).

I will keep you up to date on this status of this problem.

 Sincerely,

 Doug Olson
 Microsoft Developer Support

#: 16114 S7/Tools-Microsoft
    29-Oct-92  13:36:04
Sb: Compiler err (assertion)
Fm: Doug Olson [Microsoft] 72350,2635
To: Brad Hines 76520,3314

Brad:

I have forwarded the information from your upload to development.  I was able
to reproduce the errors and will let you know if more information or a work
around becomes available.

 Thanks,

 Doug Olson
 Microsoft Developer Support

#: 15961 S7/Tools-Microsoft
    28-Oct-92  08:20:24
Sb: WinDbg startup problem
Fm: Jim Young 72760,725
To: Sysop (X)

I have a slight annoying problem when using WinDbg. I'll start up WinDbg by
entering on the command line "WINDBG MYAPP.EXE" and everything starts up like
it should. In WinDbg I'll open up a window to the source code and do a step
into my program. As soon as it starts to execute the first code in my program
I'll get the message "Can't find WINMAIN.CPP", which brings up a file open
dialog box to select the source code for the program. I'l already have the
source window open anyway but if I go ahead and select the file with my source
code WinDbg seems satisfied and continues on. Any ideas about what is going on
here? Thanks.

--Jim

There are 2 Replies.

#: 15993 S7/Tools-Microsoft
    28-Oct-92  15:32:07
Sb: #15961-WinDbg startup problem
Fm: Doug Olson [Microsoft] 72350,2635
To: Jim Young 72760,725 (X)

Jim:

Is this a MFC application?

Thanks,

 Doug Olson
 Microsoft Developer Support




There is 1 Reply.

#: 16122 S7/Tools-Microsoft
    29-Oct-92  14:22:52
Sb: #15993-WinDbg startup problem
Fm: Jim Young 72760,725
To: Doug Olson [Microsoft] 72350,2635 (X)

Yes it is a MFC application.

#: 15995 S7/Tools-Microsoft
    28-Oct-92  15:33:40
Sb: #15961-WinDbg startup problem
Fm: Paul Tissue [Microsoft] 70744,24
To: Jim Young 72760,725 (X)

Hello Jim,

When you first start WinDebug it has yet to load the application.  Thus the
source file you are opening is not associated with the process that you plan
to debug.  Once you start the debugging process the debugger now knows which
source and OBJ files are asssociated with the process.  Thus it will attempt
to open the file that contains the process entry point (main or WinMain).

Since you already have this file opened the debugger should just continue on
and use this window as the source window.  However it appear that this is not
what you are seeing.  I have made several attempts to duplicate this behavour
but I have not been successful.

When you open the source file manually do you do anything with it before you
begin debugging?  Does the same thing occur if you do not open the file first
but let WinDebug open it when you firt start stepping?  Have you seen this
behavour with other applications such as any of the Win32 SDK samples?

- Paul, Win32 SDK Developer Support




There is 1 Reply.

#: 16123 S7/Tools-Microsoft
    29-Oct-92  14:33:14
Sb: #15995-WinDbg startup problem
Fm: Jim Young 72760,725
To: Paul Tissue [Microsoft] 70744,24 (X)

When I start up WinDebug I put my application name as a parameter on the cmd
line. Windbg would start up with a blank window showing. Then I would choose
Step Over from the Run menu to step into the first line of code. In the
command window there would be the activity of the system DLL's loading. Once
that was done I would get the message about not being able to find the source
file. This would happend even if I opened my source file befor choosing Step
Over. Also, last night I saved my workspace for my debugging for the 1st time
and the problem seems to have gone away for now. When I open the source file
manually I do nothing with it in the way of editing. I haven't tried this
version of WinDbg with the sample yet.

--Jim

#: 16075 S7/Tools-Microsoft
    29-Oct-92  10:34:28
Sb: Compiler Tools
Fm: fletcher dell 76520,3512
To: Technical Support

I've manually installed the Oct '92 release of WINNT and WIN32 per the
instructions I received.  The OS looks fine but I cannot locate the compiler
or linker.  Can you please tell me exactly how to run these, what the file
names are and where to go on the CD to find these files.  I am running on an
Intel 486 system. Also, I would like to give you feedback on the Beta release,
how do I do this?

There is 1 Reply.

#: 16141 S7/Tools-Microsoft
    29-Oct-92  16:47:33
Sb: #16075-Compiler Tools
Fm: Paul Tissue [Microsoft] 70744,24
To: fletcher dell 76520,3512 (X)

Hello Fletcher,

If you did install Windows NT and then installed the Win32 SDK using the
manual method then you must have specified the destination drive as follows:
   'MANUAL <drive:>' Thus the tools are located on <drive:>\MSTOOLS.  The
binaries are located in <drive:>\MSTOOLS\BIN.  While under Windows NT you
should run the <drive:>\MSTOOLS\SETENV.BAT file to setup you build
environment.  You can then switch to the <drive:>\MSTOOLS\SAMPLES and compile
the SDK sample by running the MAKEALL.BAT file.

>> Also, I would like to give you feedback on the Beta release, how do I do
this? <<

Please post end user beta feedback on the WINNT forum and SDK and application
development feedback on the MSWIN32 forum.  Please see the release note for
details on how to use these CompuServe forums.

- Paul, Win32 SDK Developer Support

#: 16092 S7/Tools-Microsoft
    29-Oct-92  12:07:50
Sb: Signal Anomaly
Fm: Andrew Potter 71075,614
To: all

The following program seems to act a little strange:

------------------- cut here ----------------------------------

#: 16144 S7/Tools-Microsoft
    29-Oct-92  17:09:13
Sb: #16092-Signal Anomaly
Fm: David Taniguchi [MS] 72350,2054
To: Andrew Potter 71075,614 (X)

Hi Andrew,
  Please post this in the base section (section 6 of this forum).  They are
  more experienced with these issues.
  Thanks,
  Dave

#: 15916 S7/Tools-Microsoft
    27-Oct-92  18:00:30
Sb: Mult. Inher. vs CObject
Fm: Ken Westerback 73547,3520
To: Sysop (X)

Help!

I am trying to create a new class

        class CXWnd: public CWnd, public CObList{};

but the compiler insists on warning me that CXWnd::delete is ambiguous, could
be CWnd::CObject::delete, or could be CObList::CObject::delete.

Is there a way to accomplish what I need here?  e.g. would it be safe to go
into the MFC source and change the inheritance tree so that CObject is derived
via a virtual class into CObList and CWnd?  If so, why isn't this done
already?

                                ---- Ken



There are 2 Replies.

#: 16111 S7/Tools-Microsoft
    29-Oct-92  13:35:47
Sb: #15916-Mult. Inher. vs CObject
Fm: Doug Olson [Microsoft] 72350,2635
To: Ken Westerback 73547,3520 (X)

Ken:

Let me look into this and get back with you.

 Thanks,

 Doug Olson
 Microsoft Developer Support

#: 16147 S7/Tools-Microsoft
    29-Oct-92  17:39:27
Sb: #15916-Mult. Inher. vs CObject
Fm: Doug Olson [Microsoft] 72350,2635
To: Ken Westerback 73547,3520 (X)

Ken:

Please take a look at MFC Technical Note #16.  It addresses this issue.  This
Technical note can be found at \MSTOOLS\MFC\DOC\TN016.txt.

Please let me know if you have any additional questions.

 Sincerely,

 Doug Olson
 Microsoft Developer Support

#: 15991 S7/Tools-Microsoft
    28-Oct-92  15:25:49
Sb: Too Many S
Fm: Thomas Holaday, GAT Corp 76244,1532
To: Sysop (X)

The engineer responsible for porting our application to Windows NT reports
that the October Beta, at linktime, crashes with the message

     "Exception BreakPoint has occurred"

The program emitting this complaint is CVPACK.

The library we are linking with is 397864 bytes.  Our source file is 4920
characters of .c, and its object is 100145 bytes (with symbolic debugging
information enabled).  The .exe is 442880, but we don't think it's complete
and does not execute.

Are we the only ones with this problem?

There is 1 Reply.

#: 16152 S7/Tools-Microsoft
    29-Oct-92  18:12:55
Sb: #15991-Too Many S
Fm: Doug Olson [Microsoft] 72350,2635
To: Thomas Holaday, GAT Corp 76244,1532

Thomas:

I am sorry to hear that you are encountering a problem.  I am forwarding this
problem report to our development group and will let you know the outcome.

The .EXE file should execute normally even though CVPACK failed.  The
difference will be that WINDBG will not load the symbols from the file when
you debug the application.

I may ask you for a sample that reproduces the problem.

 Thanks,

 Doug Olson
 Microsoft Developer Support

#: 16157 S7/Tools-Microsoft
    29-Oct-92  19:47:15
Sb: Fatal Compiler Error
Fm: Bill Cohagan 74375,313
To: sysop (X)

I have uploaded to lib 7 a zip file which contains a small source file and
batch file which will demonstrate a fatal compiler error.  I reported this
error yesterday, but have now whittled the source file down to a small size
which still has the problem.  There is a read.me file in the zip.

I'd appreciate some fix for this as it has pretty well blown me out of the
water in my development efforts on NT.

Thanks in advance,
 Bill

#: 16060 S7/Tools-Microsoft
    29-Oct-92  08:03:05
Sb: Preprocessor Limit
Fm: David M. Smith 76337,3225
To: Doug Olson [Microsoft] 72350,2635 (X)

Doug:

I am still getting a "fatal error C1056: compiler limit out of macro expansion
space" error with some of my code that has nested macros that expand to > 33k
bytes.

The problem has not been fixed in the Oct. SDK release.

This code will compile on many other platforms as well as Watcom's 32 bit
compiler.  Is there any hope that this limit will be removed any time soon?

Thanks for any help. Dave Smith

There is 1 Reply.

#: 16158 S7/Tools-Microsoft
    29-Oct-92  19:50:28
Sb: #16060-Preprocessor Limit
Fm: Doug Olson [Microsoft] 72350,2635
To: David M. Smith 76337,3225 (X)

David:

You are right, the macro expansion buffer is still 16K in size.  I will check
on the status of this issue. There was a particular interest in this when I
reported it a couple months ago.  I will let you know what I find.

 Sincerely,

 Doug Olson
 Microsoft Developer Support




There is 1 Reply.

#: 16166 S7/Tools-Microsoft
    29-Oct-92  23:21:28
Sb: #16158-Preprocessor Limit
Fm: David M. Smith 76337,3225
To: Doug Olson [Microsoft] 72350,2635 (X)

Doug:

Thanks for looking into this for me.  I thought that the problem would be
fixed in the Oct. release since I didn't hear anything new after reporting
this for the July SDK version.

Thanks again, David Smith

#: 16094 S7/Tools-Microsoft
    29-Oct-92  13:21:07
Sb: "leave" a reserved word?
Fm: Ed Andrews 73010,101
To: sysop (X)

Is "leave" a reserved word?  I ask because the following program will
not compile:

------------------------------cut here------------------------------

#: 16156 S7/Tools-Microsoft
    29-Oct-92  19:47:07
Sb: #16094-"leave" a reserved word?
Fm: Bill Cohagan 74375,313
To: Ed Andrews 73010,101 (X)

Ed -


 |Is "leave" a reserved word?  I ask because the following program will
 |not compile:

This is just a guess, but "leave" *is* an 80x86 instruction so it may well be
reserved in MS C/C++.  Like I said, just a guess.  Hopefully MS will give you
a definitive answer shortly.

Bill

There is 1 Reply.

#: 16188 S7/Tools-Microsoft
    30-Oct-92  09:01:45
Sb: #16156-"leave" a reserved word?
Fm: Ed Andrews 73010,101
To: Bill Cohagan 74375,313 (X)

Yes, "leave" is a assembly instruction, but what strikes me is that
there was an extra underscore prepeneded.  It turned "_leave" to
"__leave".  Even if "leave" is reserved, "_leave" is not.

#: 16201 S7/Tools-Microsoft
    30-Oct-92  11:18:40
Sb: #16094-"leave" a reserved word?
Fm: Paul Tissue [Microsoft] 70744,24
To: Ed Andrews 73010,101

Hi Ed,

I have been told by the C++ folks that '_leave' is a reserved word for
exception handling (part of the try-except & try-finally constructs, yet the
feature is not implemented yet).  Please choose a different name for your
variables.  Thanks.

- Paul, Win32 SDK Developer Support

#: 16206 S7/Tools-Microsoft
    30-Oct-92  12:56:41
Sb: RemoveDir()
Fm: Andrew Bradnan [Erudite 70402,63
To: ALL

All:

       This is a MSSETUP question, point me in the right direction if I am in
the wrong place.
       IAC, using Windows NT or Windows 3.1 (16bit) setup fails on
RemoveDir().  The directory is empty and DoesDirExist says it is there but it
still does not work.  It is giving me the API error not BadArg1 error. The
only thing I can think of is that I am in the current directory and the OS is
dumping on me for that.
       Thanks in advance,

       Andy

#: 15880 S7/Tools-Microsoft
    27-Oct-92  12:32:20
Sb: linker bug?
Fm: Colin Stuart [Microsoft] 70744,25
To: Mark L Hornick 70413,1717 (X)

Mark, I am unable to reproduce the behavior you describe unless I make sub1()
and sub2() static, thus preventing external linkage.  Otherwise, I get symbol
multiply defined errors. Also in multi-threaded apps, you should include -d_MT
on the compile line if linking with LIBCMT.LIB (and also -d_DLL if linking
with CRTDLL.LIB). If none of this works, please see if you can reproduce this
in a simple example and get back to me.

Thanks, Colin




There is 1 Reply.

#: 16218 S7/Tools-Microsoft
    30-Oct-92  14:03:50
Sb: #15880-linker bug?
Fm: Mark L Hornick 70413,1717
To: Colin Stuart [Microsoft] 70744,25 (X)

Colin,
My solution was to simply rename any functions that were defined a second time
-- that fixed the problems I was seeing. I have not tried to reproduce the
problem yet with the beta version, but will try to get around to it. So far, I
haven't been using the -d_MT or -d_DLL flags and things have been working just
fine.
Thanks, Mark

#: 15861 S7/Tools-Microsoft
    27-Oct-92  09:29:36
Sb: Preprocessor problem
Fm: Mike Markley 72401,3051
To: all

I have run into a problem with the October Beta with the C preprocessor. I get
errors when #define statements don't start in the first column. This was not a
problem with the July build. any ideas?

Mike Markley

There is 1 Reply.

#: 15902 S7/Tools-Microsoft
    27-Oct-92  15:25:11
Sb: #15861-Preprocessor problem
Fm: Paul Tissue [Microsoft] 70744,24
To: Mike Markley 72401,3051 (X)

Hi Mike,

I have been unable to reproduce this problem.  I inserted spaces and tabs in
front of several #define statements and the preprocessor handled just fine on
the test case I tried.  Could you upload an example of a file which
demonstrates this?  Also I have a few questions:

 1. Is this using the MIPS (and which one) or the x86 compiler?
 2. What type a character preceded the #define?  Spaces, tabs, other?
 3. Was this error produced on the very first non-column one aligned
    #define statement or did it occur after several were processed?
 4. Did the error occure in one of you header files or one supplied with
    the SDK?

- Paul, Win32 SDK Developer Support




There is 1 Reply.

#: 15988 S7/Tools-Microsoft
    28-Oct-92  14:04:13
Sb: #15902-Preprocessor problem
Fm: Mike Markley 72401,3051
To: Paul Tissue [Microsoft] 70744,24 (X)

Paul,

This was in one of our header files and it was inside a #ifdef. There is one
tab tab in front of the #define statement. I am running the MIPS October build
on an Olivetti PWS4000. It may somehow be related to the #ifdef. example:

#: 16026 S7/Tools-Microsoft
    28-Oct-92  19:17:09
Sb: #15988-Preprocessor problem
Fm: Paul Tissue [Microsoft] 70744,24
To: Mike Markley 72401,3051 (X)

Hi Mike,

I tried the sytnax that you descibed but the MIPS compiler accepted it. Please
upload a sample which duplicates this.  Thanks.

- Paul, Win32 SDK Developer Support




There is 1 Reply.

#: 16059 S7/Tools-Microsoft
    29-Oct-92  07:38:36
Sb: #16026-Preprocessor problem
Fm: Mike Markley 72401,3051
To: Paul Tissue [Microsoft] 70744,24 (X)

Paul,

Just create a file that contains one line "#include <windows.h>" On the
command line type:

cl file.c

You will get three warnings from mmsystem.h on my machine it warned about line
2811, 2812,2813, 2815. Sorry, you get four warnings I miss counted first time.
These are defines inside of #if or #ifdef statements. That seems to be where
the problem is. The message that I get is "Unknown Control Statement".

Mike.

There is 1 Reply.

#: 16153 S7/Tools-Microsoft
    29-Oct-92  18:20:10
Sb: #16059-Preprocessor problem
Fm: Paul Tissue [Microsoft] 70744,24
To: Mike Markley 72401,3051 (X)

Hi Mike,

We have verified this to be a problem with tbe cc.exe (MIPS) and the cl.exe
(C7 MIPS) compilers.  However, we have been unable to get either of them to
generate the "#define statements must be in the first column" error.  We'll
look further into these problems and let you know what we find.  Thanks again.

- Paul, Win32 SDK Developer Support




There is 1 Reply.

#: 16222 S7/Tools-Microsoft
    30-Oct-92  15:14:49
Sb: #16153-Preprocessor problem
Fm: Mike Markley 72401,3051
To: Paul Tissue [Microsoft] 70744,24 (X)

Paul,

The problem was not an error. I was mistaken when I first reported it. The
problem is that apparently the #defines don't do anything so I lose symbols.

Mike.

#: 16199 S7/Tools-Microsoft
    30-Oct-92  10:53:03
Sb: Image Edit closes HELP
Fm: Len Gray 71630,1703
To: All

The Image Edit application is closing Windows Help when it terminates.  I
don't mean it is closing its own Help - that's an automagic function.  It is
closing *any* current Windows Help that is open.

     Regards,
     Len



There is 1 Reply.

#: 16205 S7/Tools-Microsoft
    30-Oct-92  12:02:29
Sb: #16199-Image Edit closes HELP
Fm: Paul Tissue [Microsoft] 70744,24
To: Len Gray 71630,1703 (X)

Hi Len,

I have not been able to reproduce this with the October release.  If you are
referring to the July release then please try this out on the Octber release
when you get it.  If not, please send in the exact sequence of steps which
reproduces this problem.  Thanks.

- Paul, Win32 SDK Developer Support




There is 1 Reply.

#: 16207 S7/Tools-Microsoft
    30-Oct-92  12:57:56
Sb: #16205-Image Edit closes HELP
Fm: Len Gray 71630,1703
To: Paul Tissue [Microsoft] 70744,24 (X)

Hi, Paul

Thank you for such a quick response.  I apologize for sending in hasty report.
I just booted back to NT and found that I couldn't reproduce the problem by
just opening and closing the applications in question.  Perhaps this is
something hidden deeper within NT.

When I discovered the problem I was in an NT session using a Command Prompt
window for compiling, a WinDbg window for debugging, and accessing Windows
Help with the WIN32API icon.  I thought I was going senile 'cause every time I
tried to toggle back to WinHelp it was gone!  At the time, I was working on
reproducing a bug in StretchBlt, and was starting and closing Image Edit to
test different images.

I finally reproduced the problem for my own eyes twice in a row by starting
Image Edit and closing it and watching WinHelp disappear.

I will try more to see what I can do about reproducing this, and keep my eyes
out for *any* tasks that close when they shouldn't.

     Regards,
     Len



There is 1 Reply.

#: 16224 S7/Tools-Microsoft
    30-Oct-92  15:33:03
Sb: #16207-Image Edit closes HELP
Fm: Paul Tissue [Microsoft] 70744,24
To: Len Gray 71630,1703 (X)

Hi Len,

I looks like the problem is indeed a bit more complicated.  Please let us know
if you find a way to reproduce it and we'll attempt to nail it down. Thanks
again.

- Paul, Win32 SDK Developer Support

#: 16227 S7/Tools-Microsoft
    30-Oct-92  15:38:15
Sb: fatal compiler error
Fm: Orin Eman 71102,705
To: sysop (X)

I am getting a fatal error C1001: INTERNAL COMPILER ERROR (compiler file
'msc1.cpp', line 555).

This did not happen with the July release.

I have not been able to track this down to a small example yet, though I have
one case where taking "friend class foo;" out of one of my class definitions
makes the error go away!.

Has anyone else seen this?

#: 16124 S7/Tools-Microsoft
    29-Oct-92  14:36:53
Sb: CFile destructor
Fm: Jim Young 72760,725
To: Sysop (X)

In the InitInstance() function of my application derived from CWinApp I create
a CFile object to read in some configuration data. If CFile::Open fails (file
not found) then a default set of data is used. The problem I'm having is in
the CFile destructor where it does an ASSERT on the value of the file handle
before automatically closing the file. If the file could not be opened then
the file handle is invalid and the ASSERT fails, ending the program. Is there
any way around this? Also the CFile object is a stack variable but the
destructor does not get called until the end of the program instead of when
the variable goes out of scope when exiting the InitInstance() function. Any
comment on this? Thanks.

--Jim

There is 1 Reply.

#: 16230 S7/Tools-Microsoft
    30-Oct-92  15:42:26
Sb: #16124-CFile destructor
Fm: Julie Solon [Microsoft] 71075,107
To: Jim Young 72760,725

Jim,

This is regarding your question about preventing an ASSERT on an invalid file
handle from ending your program.  I think that what you would like to try is
structured exception handling, using try/catch.  Take a look at the "Class
Libraries User's Guide", page 61, Exception Handling.  Other references are
listed there as well.

Regarding the question about the destructor for the CFile object on the frame
not being called until the end of the program, how are you declaring the
object?  With new?  I'll need more information in order to look into that
issue.


Thanks,

Julie Solon Microsoft Developer Support

#: 16194 S7/Tools-Microsoft
    30-Oct-92  10:43:55
Sb: Link Prob. (out o' mem)
Fm: Ken Joyner 75140,256
To: Sysop (X)

When trying to link I get an "Out of memory" error. I have the october
release.  I have 16M on my machine.  What is the problem

IS THERE A BUG LIST?????

Bryan Sera

There is 1 Reply.

#: 16234 S7/Tools-Microsoft
    30-Oct-92  16:05:06
Sb: #16194-Link Prob. (out o' mem)
Fm: David Taniguchi [MS] 72350,2054
To: Ken Joyner 75140,256 (X)

Hi Ken,
  Try clearing space on the drive where the temp environment variable is
  pointing.  Have you noticed this behavior after a fresh re-boot?

  > IS THERE A BUG LIST?????

  We try to document the known bugs in the Knowledge Base.

  Let me know if this doesn't help,

  Dave Taniguchi,  Win32 SDK Developer Support

#: 16170 S7/Tools-Microsoft
    29-Oct-92  23:49:20
Sb: MFC (NT) lib comp error
Fm: Nigel Chorley 100013,1717
To: Sysop (X)

I am using the July 92 version.
I tried to compile the MFC library  (nmake model=N in dir mstools/mfc/src)
and got an error...

window.cpp (359):error C2446:'=' no conversion
      between 'int (__near__cdecl*)(void)' and 'void__near*'

All previous MFC lib files had compiled OK.

Can you help
Thanks, Nigel Chorley


There is 1 Reply.

#: 16236 S7/Tools-Microsoft
    30-Oct-92  16:12:10
Sb: #16170-MFC (NT) lib comp error
Fm: Julie Solon [Microsoft] 71075,107
To: Nigel Chorley 100013,1717

Nigel,

I was able to successfully execute

   nmake model=N

and build the NafxcWD flavor of the MFC libraries using the October beta. I
have been unable to test this on the July Release, but there have been no
problems reported with doing so.

I would double-check that your environment variables have not changed since
you were able to successfully build an MFC library.  You might be picking up a
different header file or picking them up in a different order.  The mfc
include files should be second on the INCLUDE environment variable.  I can not
think of anything else that might cause this.  Hopefully you won't have this
problem when you update to the October release.  However, please let us know
if you do.


Thanks,

Julie Solon Microsoft Developer Support

#: 16242 S7/Tools-Microsoft
    30-Oct-92  17:59:37
Sb: CVPACK Error
Fm: Koby 71172,2722
To: sysop (X)

I am building an application that was build with no CVPACK error under the
July NT vertion. The same application with the same makefile generate a Make
error U1077 after CVPACK return with return code #128, when compiled and link
under the October NT version. Any idea what cause the error.
Thanks, Koby.

#: 16253 S7/Tools-Microsoft
    30-Oct-92  19:07:38
Sb: problems with Oct rel.
Fm: Marco Papa 70353,3446
To: ALL

This is the full list of problems I encountered when installing and
recompiling/relinking using the October release on an Olivetti PWS4000.

1. First of all the docs on p. 36 of the Release notes fail to mention that on
the PWS4000 all the old environment settings are not good, and one has to Load
Default Config/Load Default Environ and change the load values.

Moreover, while the Setup defaults to \WINNT, the loaded defaults set the
OSLOADFILENAME to \NT\system\ntoskrnl.exe which of course would conflict if
one were to load the system on \WINNT. I responded to Setup changing the
default from C:\WINNT to C:\NT and allwas well.

2. On p.6 of the release notes it is said that "For RISC-based computers, the
following files are copied to the *root* of the system partition:
... HAL.DLL, OSLOADER.DLL."

This is not true. Both of the above files were written in the same location of
the July Release: \os\nt\osloader.exe and \os\nt\hal.exe.  In faxt the default
environment for OSLOADER is
scsi(0)disk(0)rdisk(0)partition(1)\os\nt\osloader.exe

and that is exactly were the files went.

3. When compiling resources built with the Windows 3.1 dialog editor, the NT
resource compiler will break immediately when processing multiple .DLG files
that all contain an initial line of DLGINCLUDE. The July release of the NT
Resource compiler did not have this pnroblem.  Also this makes .DLG files from
Windows 3.1's Dialog Editor totally imcompatible with NT.

4. If one uses the default switches from ntwin32.mak of -g2 for compilation
and -c for mip2coff, on MIPS the files are generated so large, that a project
like mine (over 70 files) will not even stay on a 200 Meg disk. The files
*before* processing by mip2coff are already huge (many even over 1 Meg for a
50K source file) and after mip2coff can be between 5 to 10 Meg for a single
file. This tells me that there is something really wrong with the current
debugging stuff on MIPS in the October release. None of these problems were
apparent in the July release.

5. If one does not use the -g2 switch in compilation, but uses the -c with
MIP2coff after compilation, MIP2coff will bomb with an "unsupported language

#: 16254 S7/Tools-Microsoft
    30-Oct-92  19:09:01
Sb: problems (continued)
Fm: Marco Papa 70353,3446
To: ALL

found in ..." message.

Given the two above problems, debugging on MIPS with the October release is
practically impossible. I could only build my app by taking out both the -g2
flag from compilation and the -c flag from MIp2coff. The file got linked OK,
but of course it has no debugging info any more.  Given this, the October
release is worse than the July one as far as debugging on MIPS is concerned.

-- Marco

#: 16086 S7/Tools-Microsoft
    29-Oct-92  11:14:48
Sb: *MAJOR* bug with new rel
Fm: Marco Papa 70353,3446
To: ALL

I have encountered a *major* problem with the October release which is
completely swrewing up the possibilities of running our app on this release at
COMDEX in the MS booth.

After rebuilding my app (a large terminal program), if I run it, the loader
will fail with a message to the effect that "The Dynamic Link Library
USERRTL.DLL could not be found in the specified path...".

It turns out that USERRTL.DLL *was* included in the July release, but is
nowhere to be seen in the October release. From snooping at the July release
DLL, this file is said to include the "Windows User Client Portion" and
includes a large quantity of major APIs.

Note that I have reproduced this problem on MIPS.  I have not tried this on a
486.

What I can guess is that the stuff that used to be in USERRTL.DLL has been
moved to another DLL or EXE, but *some* LIB file(s) provided in MSTOOLS still
refer to the old DLL from the July release.

Since we need to ship our machines with the October Release to the MS booth at
COMDEX within a couple of days, we'd appreciate a fix this week from MS.  Feel
free to call me at [phone] for any details.

-- Marco Papa



There are 2 Replies.

#: 16103 S7/Tools-Microsoft
    29-Oct-92  13:30:36
Sb: #16086-*MAJOR* bug with new rel
Fm: Colin Stuart [Microsoft] 70744,25
To: Marco Papa 70353,3446 (X)

Marco, The API in USERRTL.DLL were distributed throughout other DLLs.  The
October Beta requires a complete rebuild of all components, preferably using
the new MSWIN32.MAK. We have encountered no problems with references to
USERRTL.DLL. There is no guarantee that the library names and contents are
going to remain constant between builds, which is why I recommend using the
MSWIN32 makefile. If the problem persists, please let me know where the
references to USERRTL.DLL are occurring.

Thank you, Colin





There are 2 Replies.

#: 16168 S7/Tools-Microsoft
    29-Oct-92  23:28:03
Sb: #16103-*MAJOR* bug with new rel
Fm: Marco Papa 70353,3446
To: Colin Stuart [Microsoft] 70744,25 (X)

Sorry, but I *did* recompile ALL sources with MSWIN32.MAK. The only change I
made is to *not* use the debugging stuff.  Since I recompiled everything with
the new .LIBs I am assumiming somebody is still calling the old' DLLs.

-- Marco

#: 16171 S7/Tools-Microsoft
    30-Oct-92  00:25:15
Sb: #16103-*MAJOR* bug with new rel
Fm: Marco Papa 70353,3446
To: Colin Stuart [Microsoft] 70744,25 (X)

Hold it! I finally figured out what the problem was. By using an editor I
searched for the ".dll" string in  my program. I found no reference to the
USERRTL.DLL library that was causing the fault.  The I looked at the DLLs I
call and had recompiled with the Oct rel and all was OK there too.

The I searched for all 'old' versions of such DLLs and lo and behold I had one
DLL that was compiled with the July release.  It turns out that the faulty one
was picked up by the loader from the path "before" the one that I had rebuilt.
I deleted it and all is well now.  It would have been much easier id the
loader had mentioned the DLL name as the one that was causing the call to the
missing DLL, while instead it mentioned the name of the calling program.
Doesn't the loader have the info on the caller (i,e. can't it distinguish
between the main and a DLL called by it?).

Anyway, all is well and we're ready for COMDEX. Sorry fo jumping the gun.

-- Marco



There is 1 Reply.

#: 16213 S7/Tools-Microsoft
    30-Oct-92  13:10:29
Sb: #16171-*MAJOR* bug with new rel
Fm: Paul Tissue [Microsoft] 70744,24
To: Marco Papa 70353,3446 (X)

Hi Marco,

Great to hear things are working now!

BTW, I have passed along your suggestion of indicating which module is calling
the errant DLL to our developers.

- Paul, Win32 SDK Developer Support




There is 1 Reply.

#: 16255 S7/Tools-Microsoft
    30-Oct-92  19:12:29
Sb: #16213-*MAJOR* bug with new rel
Fm: Marco Papa 70353,3446
To: Paul Tissue [Microsoft] 70744,24 (X)

Thanks, Paul.  I can surely say that if the message would have mentioned the
DLL I could have found the problem in no more than a few minutes, by just
checking the named file.  Since my program calls quite a number of mine and
system DLLs and the message named my program (the main I mean), I started
looking in the wronmg place, and wasted quite some time looking in the wrong
place.  At any rate, all is well, and we're ready for COMDEX. BTW, the
performance of the screen update in the Oct release seems much improved.  Is
this just a personal impression?

-- Marco

#: 16154 S7/Tools-Microsoft
    29-Oct-92  18:20:16
Sb: #16086-*MAJOR* bug with new rel
Fm: Paul Tissue [Microsoft] 70744,24
To: Marco Papa 70353,3446 (X)

Hello Marco,

Colin meant to refer to the NTWIN32.MAK file (not the MSWIN32.MAK file which
does not exist).  Please let us know if rebuilding your application does not
make this DLL reference go away.  Thanks again.

- Paul, Win32 SDK Developer Support




There is 1 Reply.

#: 16169 S7/Tools-Microsoft
    29-Oct-92  23:31:19
Sb: #16154-*MAJOR* bug with new rel
Fm: Marco Papa 70353,3446
To: Paul Tissue [Microsoft] 70744,24 (X)

As I mentioned, I did rebuilt rhe complete app from scratch. I erased all the
.objs and the .res files, recompiled and relinked.  And as I said I used the
NTWIN32.MAK file except that I did not use the -g2 flag in compilation and the
-c flaf in mip2coff since with them my app becomes a humongous > 100 Meg file
(I'll submit a bug report on this one soon).

-- Marco

#: 16257 S7/Tools-Microsoft
    30-Oct-92  19:19:50
Sb: Oct/July NT coexist?
Fm: Bill Cohagan 74375,313
To: sysop (X)

It appears that I am going to have to drop back to the July SDK because the
October release compiler can't compile my application.  Is it possible for the
July and October releases to coexist on my disk (I think I have enough room,
barely!)?

I'm trying to determine if I must *delete* the October directories and run a
full install of the July release or can I just have a different pair of
directories, mstools & winnt, for each release?  Does the install put any
release dependent code in the root or elsewhere (other than mstools and
winnt?)

I'd like to keep the October release around 'cause I'd rather not reinstall it
*again*. This assumes the compiler will be fixed or a workaround provided
fairly quickly -- otherwise the October release gets tossed.

Thanks in advance,
 Bill

#: 16020 S7/Tools-Microsoft
    28-Oct-92  19:14:55
Sb: C++ syntax errors?
Fm: Bill Cohagan 74375,313
To: sysop (X)

Under the October release C++ compiler I'm getting syntax errors with code
which compiled fine under the July release.  The situation is roughly:

In a header file I have; e.g.,

 #define foo (tpIVAL(AN_ENUMERATION_CONSTANT))

where tpIVAL is a class for which an appropriate conversion (constructor) is
defined (previously in the same header file.)  It may be significant that the
constructor body is defined in the header; i.e., it is an "inline" conversion.
Now, in a cpp file which includes this header I have a reference of the form:

 Baz x = foo;

where Baz is the direct base class of tpIVAL.  As I said, this *used* to
compile OK. Now I get a syntax error referring to a constant referenced in the
*expansion* of the tpIVAL(short) constructor and a subsequent complaint about
an illegal cast to a function type.

Finally, (and perhaps most significant) if I remove the outer parens in the
macro for foo, everything seems to compile OK! I think this is a bug unless
I've misread the syntax for expressions in C++; i.e., you ought to be able to
wrap an arbitrary expression in parens without breaking anything, right?

Thanks,
 Bill

There is 1 Reply.

#: 16229 S7/Tools-Microsoft
    30-Oct-92  15:42:21
Sb: #16020-C++ syntax errors?
Fm: Julie Solon [Microsoft] 71075,107
To: Bill Cohagan 74375,313 (X)

Bill,

This looks like a problem to me as well.  I received no errors from C 7.0, but
I received the following errors from cl386 .033 compiling the code below

   C2061: syntax error : identifier 'red'
   C2066: cast to function type is illegal
   C2059: syntax error : ';'

I would like to check and see if our samples are somewhat similiar and that
the error messages are the same before I file a formal report to development.
If I remove the outer parens, I get error C2243, which I would expect, with
the way the classes are defined in my example (Baz x = foo; assigns derived
class object to base class object).  Please let me know.

Thanks,

Julie Solon Microsoft Developer Support

// test.h enum color { red, blue, green }; #define foo ( tpIVAL( red ) )

class Baz {
   int var;

public:
   Baz( short s ) { var = s; }
   Baz( ) { var = 0; } };

class tpIVAL : Baz {
   short i;

public:
   tpIVAL( color c ) { i = c; }
   tpIVAL( ) { i = 0; } };


// test.cpp #include "test.h"

Baz x = foo;

void main( ) { }




There are 2 Replies.

#: 16256 S7/Tools-Microsoft
    30-Oct-92  19:19:42
Sb: #16229-C++ syntax errors?
Fm: Bill Cohagan 74375,313
To: Julie Solon [Microsoft] 71075,107 (X)

Julie-
  I'll try to whittle my source down to a small example which illustrates this
problem.

Thanks for the response.
 Bill

#: 16258 S7/Tools-Microsoft
    30-Oct-92  19:20:00
Sb: #16229-C++ syntax errors?
Fm: Bill Cohagan 74375,313
To: Julie Solon [Microsoft] 71075,107 (X)

Julie-
  It looks to me like you've got the same problem I described.  Following is a
version of my code which illustrates the problem:
===============================cut here================================

  enum IVAL_SUBTAG{
      NULL_IVAL_SUBTAG = 0x02,
      UNDEF_IVAL_SUBTAG = 0x04
  };

  #define NULL_OBJ (tpIVAL(NULL_IVAL_SUBTAG))

  class tpIVAL {
    public:
      unsigned image;
      tpIVAL(short i){image = i;}
  };

  tpIVAL foo = NULL_OBJ; ==================================cut
here=============================

This gives me the following error messages:


  C:\NTSCHEME>cl386 /c /G3d /W3 /Zi /Od /D_DEBUG /D_NTWIN /D_WINDOWS
/DWINVER=0x030a /Di386=1 bug3.cpp
  bug3.cpp
  bug3.cpp(15) : error C2061: syntax error : identifier 'NULL_IVAL_SUBTAG'
  bug3.cpp(15) : error C2066: cast to function type is illegal
  bug3.cpp(15) : error C2059: syntax error : ';'

I compiled with:

 cl386 /c /G3d /W3 /Zi /Od /D_DEBUG /D_NTWIN /D_WINDOWS /DWINVER=0x030a
/Di386=1 bug3.cpp

Thanks for looking into this.
 Bill




#: 15849 S8/CPU-MIPS Specific
    27-Oct-92  04:51:28
Sb: Magnum R4000 for NT dvlp
Fm: Robin 100025,604
To: ALL

Can anyone tell me where (if ?) Silicon Graphics support their MIPS machines
on Compuserve ?

Also (as I haven't received any documentation yet) can anyone recommend any
books about their machines (particularly the Magnum R4000), particularly about
the CPU and programming it at assembler level.

Many thanks in advance,

Robin Duerden.


There are 2 Replies.


#: 15905 S8/CPU-MIPS Specific
    27-Oct-92  15:45:56
Sb: #15849-Magnum R4000 for NT dvlp
Fm: Petrus Wong [Microsoft] 70743,3355
To: Robin 100025,604 (X)

Robin:

 >>Also (as I haven't received any documentation yet) can anyone recommend any
books about their machines (particularly the Magnum R4000), particularly about
the CPU and programming it at assembler level.<<

 There are two books on the MIPS R4000 that I know of.  They are:

       1. MIPS RISC Architure by Kane/Heinrich         Prentice Hall
       2. MIPS R4000 Microprocessor User's Manual      mips



 petrus

#: 15908 S8/CPU-MIPS Specific
    27-Oct-92  16:14:18
Sb: #15849-Magnum R4000 for NT dvlp
Fm: Arthur Kreitman 76060,2677
To: Robin 100025,604 (X)

>Also (as I haven't received any documentation yet) can anyone >recommend any
books about their machines (particularly the Magnum >R4000), particularly
about the CPU and programming it at assembler >level.
  I hope you're not planning to write MIPS assembler code.  The
compiler is smarter when it come to those things that make RISC
fast (scheduling, delayed branches...). Not only
that, MIPS assemble code is undebugable.   Not only the complier
does optimizatiom. but also the linker.  A friend of mine
tried this a few years ago.  He discovered that the code
was reordered



There is 1 Reply.

#: 16093 S8/CPU-MIPS Specific
    29-Oct-92  12:09:15
Sb: #15908-Magnum R4000 for NT dvlp
Fm: Petrus Wong [Microsoft] 70743,3355
To: Arthur Kreitman 76060,2677 (X)

 >>I hope you're not planning to write MIPS assembler code.  The compiler is
smarter when it come to those things that make RISC fast (scheduling, delayed
branches...). Not only that, MIPS assemble code is undebugable.   Not only the
complier does optimizatiom. but also the linker.  A friend of mine tried this
a few years ago.  He discovered that the code was reordered<<


 The books that I mentioned earlier talks about the kind of code reordering
you were talking about...

 petrus




#: 15778 S9/CPU-x86 Specific
    26-Oct-92  09:43:40
Sb: #15704-DDK
Fm: David Taniguchi [MS] 72350,2054
To: Frank Natoli [Discovery] 70744,3705

Hi Frank,
  >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?

  The Preliminary DDK will be available before the end of November.  The
  cost is as follows:

   DDK CD-ROM only                         $69
   DDK CD-ROM with hard-copy documentation $399

  This pricing includes updates and the final version of the DDK.  The
  documentation will be included on the CD in both Postscript and Write
  format, and all the device driver functions will be documented in Winhelp.

  If you are in the US and currently own the Win32SDK, you will be receiving
  a mailing on the DDK in mid-November which will include 4-page product
  datasheet and an order coupon.  We encourage you to order via this coupon
  since we are unable to keep up with extremely high call volumes the past
  few weeks.  You will receive this coupon in plenty of time before the
  product ships.

  International customers should contact their local MS office for ordering,
  pricing and availibility information.

  One other important change which you should be aware of.  Everyone who
  purchases the hard-copy documentation for the DDK will receive the new
  book "Inside Windows NT" from MS Press.  This book will not be on the
  CD.

  Hope this helps,
  Dave


#: 15743 S9/CPU-x86 Specific
    25-Oct-92  05:26:37
Sb: Fatal Error, July Rel.
Fm: Wim Bonner 72561,3135
To: microsoft

I ran a program that I expected to allcate close to 20 megabytes of memory
using malloc calls overnight last night.  (My system has 32 meg of memory)
When I came in this morning, the following message was on a blue screen on my
system:

Fatal System Error 0x0000000A

IRQL expected to be less or equal

I don't know when it would have happened, because after I read in the entire
20 meg data file, parsing it into a huge pointer linked structure, I call GDI
routines to display the entire thing.

Can you tell me if the problem most likely occurred while I was reading in the
file or if it most likely occurred while I was drawing?

Wim.f

There is 1 Reply.

#: 15790 S9/CPU-x86 Specific
    26-Oct-92  12:09:10
Sb: #15743-Fatal Error, July Rel.
Fm: David Taniguchi [MS] 72350,2054
To: Wim Bonner 72561,3135

Hi Wim,
  You will need to isolate this down more.  You typically get this when you
  are booting up and hardware is not configured correctly.  Another place I
  have seen this is when bad network packets are sent with tcp/ip.  If you
  can reproduce this, it would help.

  You might post in the base (Section 6) and gdi (section 5) sections to
  see if they have heard of any problems with the api's you were running.

  Thanks,
  Dave

#: 15856 S9/CPU-x86 Specific
    27-Oct-92  08:00:16
Sb: PDC/Beta Compatiblity
Fm: Timothy H. White 75300,1772
To: Sysop (X)

Help!  I ported four shareware apps and submitted them for the NT Shareware
Contest.  They were compiled with the July PDC build of NT.  Yesterday I
installed the October Beta, and nothing that was compiled with the PDC build
runs under it!

What is the procedure for getting updated builds of these apps to the correct
person at Microsoft?  Will future releases of NT (Beta or otherwise) also
present this problem?

TIA,

Timothy

There is 1 Reply.

#: 15896 S9/CPU-x86 Specific
    27-Oct-92  15:20:04
Sb: #15856-PDC/Beta Compatiblity
Fm: David Taniguchi [MS] 72350,2054
To: Timothy H. White 75300,1772 (X)

Hi Timothy,
  I believe it's only for the July Release as the cutoff was October 15th.
  As stated below, you may be requested to rebuild your application on a
  later build before Comdex, but if they haven't notified you, don't worry
  about it. :)
  Hope this helps,
  Dave

  Contest Rules: To facilitate judging, you must submit five diskettes
  for each application you send.  All submissions must be received by
  October 15th, 1992.  The winners will be announced at Fall Comdex
  '92.  Applications must be compiled to run as a native 32 bit
  application for the July or later build of the Windows NT operating
  system; you may be requested to rebuild your application on a later
  build before Comdex.  Prizes may vary depending on availability and
  number of entries received.  Applications classified under any of the
  following terms will be accepted -- retail programs, i.e., packaged
  programs that are sold in stores and via other traditional sales
 channels, will not be accepted.  Shareware - copyrighted or patented
  programs sold on a "try before you buy" basis.  FreeWare -
  copyrighted or patented programs which do not require compensation
  for use in most cases.  Public Domain - free from copyrights or
  patents; open to use by the public without compensation.  Submitted
  diskettes will not be returned.  All decisions are final.  Void where
  prohibited.





There is 1 Reply.

#: 15962 S9/CPU-x86 Specific
    28-Oct-92  08:29:51
Sb: #15896-PDC/Beta Compatiblity
Fm: Timothy H. White 75300,1772
To: David Taniguchi [MS] 72350,2054 (X)

Thanks for the reply, David.  I'm aware that the deadline has passed, I
submitted all four apps by the end of September.  I was also aware that a
recompile may be required, but I haven't heard anything from anyone.

Does this mean that nothing will be distributed at COMDEX?  Is the contest
being cancelled?

Also, will future releases of NT require recompiles also?

TIA,

Timothy

There is 1 Reply.

#: 16119 S9/CPU-x86 Specific
    29-Oct-92  14:03:07
Sb: #15962-PDC/Beta Compatiblity
Fm: David Taniguchi [MS] 72350,2054
To: Timothy H. White 75300,1772 (X)

Hi Timothy,
  As far as I know, the contest is still in progress.  I am not certain
  in what situations they would want you to recompile your application. If
  your application worked under the July Release, they will judge your app
  on the July Release.

  > Also, will future releases of NT require recompiles also?

  Yes, when the final product ships, we encourage all developers to
  recompile their applications.
  Thanks,
  Dave

#: 15964 S9/CPU-x86 Specific
    28-Oct-92  09:06:45
Sb: cpu_x86
Fm: Terry Fossey 100113,3461
To: mswin  32

I am trying to load the July release of NT onto a 386/33 system and cannot get
the PC to boot. I have tried the supplied NT boot diskette on other PCs and
these are OK untill it cannot find the CD-ROM drive and gives a message to
this effect.

My own system has a Creative Labs Soundblaster and CD-ROM combination (from
MSDN) together with 16Mb RAM and a 240Mb IDE disk.

At the bottom of the screen: Reading inf file \txtsetup.inf On the body of the
screen: TRAP 0000000E =================PAGE FAULT=============

** At linear address E84539C5

tr=0028    cr0=FFFFFFE1    cr2=E84539C5    cr3=00030000 gdt limit=03FF
base=00036000  ldt limit=07FF  base=00036400

etc etc....

Any suggestions?

There is 1 Reply.

#: 16120 S9/CPU-x86 Specific
    29-Oct-92  14:03:12
Sb: #15964-cpu_x86
Fm: David Taniguchi [MS] 72350,2054
To: Terry Fossey 100113,3461

Hi Terry,
  Please post this in Section 3 (Windows NT Setup) of Forum WinNT.  They
  are more familiar with setup issues.

  (In glancing at the Hardware Compatibility list, it appears the Creative
  Labs card is not supported.  You might look at the DOS2NT method of
  installation before posting.)

  Thanks,
  Dave

#: 15733 S9/CPU-x86 Specific
    24-Oct-92  05:49:17
Sb: stacker
Fm: steven drexler 71162,2411
To: all

Are there any plans to support stacker in the final version of window NT?/exit

There is 1 Reply.

#: 15777 S9/CPU-x86 Specific
    26-Oct-92  09:43:31
Sb: #15733-stacker
Fm: David Taniguchi [MS] 72350,2054
To: steven drexler 71162,2411

Hi Steven,
  >Are there any plans to support stacker in the final version of window NT?

  No, I don't believe there are any plans for this.


  -Dave

#: 15818 S9/CPU-x86 Specific
    26-Oct-92  17:18:34
Sb: #15777-stacker
Fm: steven drexler 71162,2411
To: David Taniguchi [MS] 72350,2054 (X)

I guess i should should just throw out my stacker board then.

There is 1 Reply.

#: 15847 S9/CPU-x86 Specific
    27-Oct-92  04:03:09
Sb: #15818-stacker
Fm: Andreas Klein 100063,1637
To: steven drexler 71162,2411 (X)

Maybe you should first ask Stac Technology about their commitment to
supporting Windows NT via a driver before throughing away hardware.
You might hurt someone <g>.

ciao,
  Andreas

There is 1 Reply.

#: 15868 S9/CPU-x86 Specific
    27-Oct-92  10:21:13
Sb: #15847-stacker
Fm: David Taniguchi [MS] 72350,2054
To: Andreas Klein 100063,1637 (X)

Andreas,
  That's a good suggestion.  I would contact them to see if they have any
  plans for adding NT support.
  Thanks,
  Dave



There is 1 Reply.

#: 16034 S9/CPU-x86 Specific
    28-Oct-92  21:20:29
Sb: #15868-stacker
Fm: steven drexler 71162,2411
To: David Taniguchi [MS] 72350,2054 (X)

I have already left a message with their new forum on this board. No plans.
Aren't they in cohoots with MS arch enemy DR anyway? /exit

There is 1 Reply.

#: 16129 S9/CPU-x86 Specific
    29-Oct-92  15:06:10
Sb: #16034-stacker
Fm: David Taniguchi [MS] 72350,2054
To: steven drexler 71162,2411

Hi Steven,
  >I have already left a message with their new forum on this board. No
  >plans. Aren't they in cohoots with MS arch enemy DR anyway?

  Not sure on this one.  I don't keep up with who is in whos camp. :)
  Thanks,
  Dave

#: 16028 S9/CPU-x86 Specific
    28-Oct-92  19:19:52
Sb: #15594-Multi processing NT
Fm: Julio C. Martinez 76535,2345
To: Jeff Nuccio 76547,2342 (X)

Jeff,

I was browsing by and happened to see your inquiri. I was looking for
infomation on multiprocessor machines capable of running NT for a research
project. Although I don't have an immediate need for the machine, I do need
some ballpark info on pricing for a proposal. If you are able to provide me
with any information on what Hauppage may have to offer I would appreciate it.

Thanks - Julio



There is 1 Reply.

#: 16181 S9/CPU-x86 Specific
    30-Oct-92  07:28:41
Sb: #16028-Multi processing NT
Fm: Andy Champ 100064,2267
To: Julio C. Martinez 76535,2345 (X)

Julio, we (ICL) provide such a machine.  It's a deskside 10-EISA slot, 4 CPU
max (486/50 or /33) up to 128Mb (256 if only 2 CPU) with up to 8 half-height
5.25 inch drives (full heights: 3 if you allow for floppy & CD).

If you want more information on it, drop me your snail-mail address & I'll get
you a brochure sent over.

In case you don't know - ICL are part of Fujitsu group & hence worlds no. 2 IT
company.

Andy Champ.

#: 15846 S9/CPU-x86 Specific
    26-Oct-92  23:57:15
Sb: SMP or Not
Fm: Jeong Ho Lee 70253,1244
To: ALL

Hello,
For overall performance, does NT prefer 66MHz Single 486 system or 33MHz
dual 486 system ? Of course, let's assume they have the same configurations
except the # of CPUs.
Thanks
jLee

There are 2 Replies.

#: 15848 S9/CPU-x86 Specific
    27-Oct-92  04:08:26
Sb: #15846-SMP or Not
Fm: Andreas Klein 100063,1637
To: Jeong Ho Lee 70253,1244 (X)

For overall performance the dual processor system is likely to be faster
because Windows NT supports multiple processors down to the Executive layer.
But remember, you need an apropriate HAL that supports your machine, while the
single processor machine is highly likely to run with one of the HAL`s
supplied by MS!

The multiprocessor system is likely to be faster because if for example one
processor is doing I/O (which can be pretty slow) the other still can work,
while in the single processor environment the whole machine has to wait before
the I/O instruction is done because it`s atomic to the CPU.

I hope this helps,
  ciao,
    Andreas

#: 16182 S9/CPU-x86 Specific
    30-Oct-92  07:28:46
Sb: #15846-SMP or Not
Fm: Andy Champ 100064,2267
To: Jeong Ho Lee 70253,1244 (X)

I disagree with Andreas to some extent.  If you run a pair of 33MHz processors
you'll get performance, depending on cache design and workload, typically
1.5-1.9 times a single processor.  In extreme cases this can fall outside
these bands.  A single processor is likely to be cheaper for the same
performance.  Trouble is the 66MHz of course isn't really a 66 - it's only
worth about a 50MHz as it's choked up by the 33MHz bus.  What you want really
is a dual (or more) 50MHz with write-back cache design to get real speed.

Now if your question was - dual 25 or single 50?  then I'd have no doubt in
recommending the single 50.

Best thing is to benchmark it.  It's not really NT that has the preference, so
much as your workload and the machine design.

Andy Champ ICL.

ps - want a sales brochure on our 1-4 CPU 33 or 50MHz machine?  AC.



There is 1 Reply.

#: 16191 S9/CPU-x86 Specific
    30-Oct-92  09:30:36
Sb: #16182-SMP or Not
Fm: Jeong Ho Lee 70253,1244
To: Andy Champ 100064,2267

Thanks,
Yes, please send me your brochure TO:

Jeong Ho Lee
Park Scientific Instruments
1171 Borregas Av.
Sunnyvale, CA 94089

jLee

#: 16161 S9/CPU-x86 Specific
    29-Oct-92  20:34:48
Sb: NT Request List/Problems
Fm: Travis Creager 74230,3121
To: sysop (X)

I have the following hardware that makes for a hot little system except that
the only things that NT supports currently supports are the mother board, the
Sound Blaster, and the hard disk.

Micronics 486/33 Gemini Motherboard Diamond SpeedStar 24X Video Card Sound
Blaster Conner 200 Meg. HD Mitsumi CD-ROM Drive with Drive Select at 0, which
is the ONLY setting
   available on this particular drive, and YES, I have opened the case to
   check!  Note that this is the same drive and controller that DAK sales
   for $200, and is thus VERY POPULAR!!! Maynard Archive XL 120/250 Meg.
Floppy based tape drive (though I plan on
   moving up to a Summit SE305 IDE-Based drive.

I want to know if and when most of this stuff is supposed to be supported.

Also, would it be possible for me to put the CD-ROM drivers in NT's bootup
script (as if I could even run the October-Beta version!)

It may be nice being a computer reseller, but I don't have $1000-2000 to
down-grade and morph over to something that is compatible with NT (and  that
is just for the video card and CD-ROM drive...Add another $2000 for the Tape
drive!!!)

There is 1 Reply.

#: 16196 S9/CPU-x86 Specific
    30-Oct-92  10:52:40
Sb: #16161-NT Request List/Problems
Fm: David Taniguchi [MS] 72350,2054
To: Travis Creager 74230,3121

Hi Travis,
  >..I want to know if and when most of this stuff is supposed to be
  supported.

  It's really up to the manufacturers of the hardware to decide if they want
  to write drivers and support NT.  Keep in mind the Device Driver
  Conference was over only 3 days ago.  Also, the Device Driver Kit itself
  (which is the software necessary to write Device Drivers) has only been
  in the hands of the most of the hardware manufacturers for 3 days!
  When the NT is released, I am certain there will be more drivers available

  >Also, would it be possible for me to put the CD-ROM drivers in NT's
  bootup script (as if I could even run the October-Beta version!)

  I am not sure what you mean here.  Any setup questions you have should
  be posted in section 3 (Windows NT setup) of the WinNT forum.  Keep in
  mind if you have an unsupported CD-ROM, you can still install if you can
  access the CD-ROM when booting from DOS.  Look at the WINNT method of
  installation.

  >It may be nice being a computer reseller, but I don't have $1000-2000 to
  down-grade and morph over to something that is compatible with NT (and
  that is just for the video card and CD-ROM drive...Add another $2000 for
  the Tape drive!!!)

  I agree.  And with several hundred developers attending the DDK conference,
  I am looking forward to seeing more devices supported myself.

  Thanks,
  Dave

#: 16200 S9/CPU-x86 Specific
    30-Oct-92  11:10:31
Sb: Setting up Win32 SDK
Fm: Martin Snowden 73617,265
To: All

Hi,
        I'm about to install the SDK (October release) for the first time,
and I would like some advice on the most efficient way of arranging
software on my disks. Here is my scenario:

        I currently have a 200 MB hard drive just about full with
MS-DOS 5.0, Windows 3.1, and all my DOS and Windows applications
etc. The drive is stacked with Stacker so on the physical drive
I have a stacked C: and an unstacked D: logical drives.
        I have now purchased a second, 340 MB hard drive so I will
have room for Windows NT, Win32 SDK etc.
        Now, what's my best approach ? If I install NT and SDK
on the new drive will I have to make that drive my boot drive from
now on ? Will that also mean the new drive will have to be (or
have on it as a primary partition)  the logical drive C: ? And
if that is so what will happen to my original C: ? - Will it
have to have a new letter and then I will have to meticulously go
through all Windows 3.1 .INI files etc. changing all references
to C: to the new letter ?
        Plus what about Stacker ? To run my existing apps. from
NT environment do I have to unstack everything ? Would I be better off
having both a stacked (for 3.1) and an unstacked version (for NT)
of these apps ?

        Before I spend a lot of time experimenting can anyone
give me some advice ?

                Thanks in advance,
                                        Marin Snowden.


There is 1 Reply.

#: 16237 S9/CPU-x86 Specific
    30-Oct-92  16:43:49
Sb: #16200-Setting up Win32 SDK
Fm: David Taniguchi [MS] 72350,2054
To: Martin Snowden 73617,265

Hi Martin,
  Please post this in section 3 (Windows NT Setup) of forum WinNT.  They
  are more familiar with these issues.

  Thanks,
  Dave

  PS: NT does not support stacked drives. I believe you would have to boot
  from a non-stacked drive.  As for the SDK, it's just a matter of
  preference.  I installed NT and the SDK on my primary C: drive.  I can
  flexboot into DOS (but I rarely do this, and I have a dedicated
  DOS/Windows machine).




#: 15918 S10/Porting from OS/2
    27-Oct-92  18:14:31
Sb: Resource Conversion
Fm: James Ross Allard 70732,1515
To: all

Are there any tools for converting OS/2 resource files to windows format?

Thanks
Ross

There is 1 Reply.


#: 15943 S10/Porting from OS/2
    27-Oct-92  22:16:45
Sb: #15918-Resource Conversion
Fm: John Hall [MS SDE] 70750,2341
To: James Ross Allard 70732,1515 (X)

Rescon.zip, this library section.
In fact, I'd strongly recommend most of my downloads, or at least
reading the abstracts for them.

I'll be posting upates for the beta and some new stuff (Queues) in
2 weeks.

There is 1 Reply.

#: 16145 S10/Porting from OS/2
    29-Oct-92  17:23:20
Sb: #15943-Resource Conversion
Fm: James Ross Allard 70732,1515
To: John Hall [MS SDE] 70750,2341 (X)

Thanks John, I'll check it out.

#: 16053 S10/Porting from OS/2
    29-Oct-92  06:44:39
Sb: Bitmaps on menus
Fm: BENJ FAYLE 71151,1603
To: John Hall 70750,2341 (X)

John,

I got your package and am well on my way to getting my system converted from
OS2.  It took quite a lot of fiddling to get the resource files converted.
Mostly commenting out various unrecognized options.  What the overall
ramifications of some of these missing will be I'm not sure yet.

Question:

How do you get bitmaps onto menus.  In OS2 resource files I use te following:

BITMAP 8100 alleft.bmp
BITMAP 8101 alcenter.bmp
BITMAP 8102 alright.bmp

MENU IDM_MAIN
{
   SUBMENU "Align ~column", IDM_ALIGNCOLUMN
   {
      MENUITEM "#8100", IDM_ALIGNLEFT, MIS_BITMAP
      MENUITEM SEPARATOR
      MENUITEM "#8101", IDM_ALIGNCENTER, MIS_BITMAP
      MENUITEM SEPARATOR
      MENUITEM "#8102", IDM_ALIGNRIGHT, MIS_BITMAP
      MENUITEM SEPARATOR
   }

What is the corresponding code to be used in windows?

Thanks,

Benj Fayle



There is 1 Reply.

#: 16083 S10/Porting from OS/2
    29-Oct-92  11:03:55
Sb: #16053-Bitmaps on menus
Fm: Nancy Cluts - Microsoft 70744,20
To: BENJ FAYLE 71151,1603 (X)

Hi Benj.

Under Windows, you can append a bitmap to a menu.  There is a sample in
Petzold's book called GAFMENU that demonstrates it.  It is in chapter 9.  In
short, you call AppendMenu( hMenu, MF_BITMAP | MF_POPUP, ..,hBitmap).

Nancy




There is 1 Reply.

#: 16266 S10/Porting from OS/2
    30-Oct-92  21:19:36
Sb: #16083-Bitmaps on menus
Fm: BENJ FAYLE 71151,1603
To: Nancy Cluts - Microsoft 70744,20

Thanks Nancy,

I've got Petzold's here at my side.  I'd already found the method you'd
pointed me to but was looking for a resource file approach.  I like the idea
of having static aspects of my code in resource files and leaving variable
features for runtime.  I should have phrased my question to ask if there was a
resource file method of placing bitmaps in menus.

On the topic of resource file conversion: In OS2 you can flag an entry field
as ES_READONLY, is there a comparable feature if Windows, either resource or
runtime?

Benj

P.S.  What does John Hall do and what do you do and who should I direct my
questions towards?




#: 15823 S11/Porting from Unix
    26-Oct-92  18:40:02
Sb: Porting from Unix
Fm: John Richardson 70541,672
To: sysop (X)

Hi, I just received my new October NT Beta SDK with the POSIX subsystem.

I have been doing some testing, and found some issues/limits:

The common command shell (cmd.exe) can only run programs that end
with .exe or .com. If I create a program foo.exe, and then copy it to
foo, in which this is the common UNIX naming for executable programs,
it will not be run by cmd.exe. I get an error that the command does
not exist.


Another issue is when I do a fork() and then an execl() from a POSIX
program, I can only execl() other POSIX programs. I can not start a
DOS or even another WIN32 program. Apparently, the standard WIN32
CreateProcess() can do this.


                                                Thanks,

                                                        JR


There are 2 Replies.


#: 15909 S11/Porting from Unix
    27-Oct-92  16:16:39
Sb: #15823-Porting from Unix
Fm: Arthur Kreitman 76060,2677
To: John Richardson 70541,672 (X)

>I have been doing some testing, and found some issues/limits:

>The common command shell (cmd.exe) can only run programs that >



  Just wait until you've discovered the real limitations

#: 15976 S11/Porting from Unix
    28-Oct-92  11:47:25
Sb: #15823-Porting from Unix
Fm: Steve Firebaugh [MS] 75430,412
To: John Richardson 70541,672 (X)

JR,  To answer the concerns you've raised:

 >The common command shell (cmd.exe) can only run programs that end
 >with .exe or .com.

This is by design.  Please notice that the POSIX support in NT is intended to
be an implementation of the IEEE 1003.1 standard.  It supports a basic POSIX
application programming interface; it does not provide a POSIX shell. If you
are looking for a unix-like shell, I am told that Doug Hamilton sells a good
one.  Please try sending him mail at compuserve address: 70034,2025.

 >Another issue is when I do a fork() and then an execl() from a POSIX
 >program, I can only execl() other POSIX programs. I can not start a
 >DOS or even another WIN32 program.

This is also by design, and is compliant with the POSIX spec.

Steve Firebaugh



There is 1 Reply.

#: 16014 S11/Porting from Unix
    28-Oct-92  18:02:57
Sb: #15976-Porting from Unix
Fm: John Richardson 70541,672
To: Steve Firebaugh [MS] 75430,412 (X)

RE: POSIX subsystem limits

I have some more issues in which I am trying to address.

The first is support for WINSOCK, or some socket abstraction that
would allow me to connect to other systems.

I also have been trying to get a named pipe from POSIX to connect
to a named pipe from WIN32. What I need to do is provide for some
communications mechanism that would allow a POSIX application to
communicate with a WIN32 program.

The specific application that I am working on right now would use an
X-server running under WIN32 which executes XLIB requests made by
applications ported to the NT POSIX subsystem. This would allow an
X-Windows based UNIX program to link with the XLIB, which would use some
communciations mechanism to talk to the X-server running as a
native WIN32 application.

Now there is no 'mixing' of the API's, just the ability to perform
interprocess communication.

If named pipes or WINSOCK is not the answer, what is the communications
mechanism that would allow me to do this?

One last question which may solve my problem, does the POSIX subsystem
let me open and access a device? If it does, I could write a virtual
device driver that would act as a communications layer for my
application.

                                                Thanks,

                                                        JR


There are 2 Replies.

#: 16072 S11/Porting from Unix
    29-Oct-92  09:12:42
Sb: #16014-Porting from Unix
Fm: Arthur Kreitman 76060,2677
To: John Richardson 70541,672 (X)

>The first is support for WINSOCK, or some socket abstraction that
>would allow me to connect to other systems.
   Nope, no sockets


>I also have been trying to get a named pipe from POSIX to connect
>to a named pipe from WIN32. What I need to do is provide for some
  Out of luck again.  No named pipes

  If you have an application that doesn't need to do anything
beyond reading and writing to a disk file, and doesn't need
any sort of screen control, the POSIX subsystem is great.

If you want to do anything worth doing, forget it.

#: 16246 S11/Porting from Unix
    30-Oct-92  18:11:09
Sb: #16014-Porting from Unix
Fm: Steve Firebaugh [MS] 75430,412
To: John Richardson 70541,672 (X)

JR,  Apparently it is not currently possible to communicate between the posix
subsystem, and other subsystems with either named pipes, or with sockets.
This obviously puts severe restrictions on the utility of a posix program
running on NT.  I am trying to figure out the recommended method of IPC
between the posix subsystem, and the rest of the NT environment.  I hope to
have more information to you by early next week.

Steve Firebaugh




#: 15751 S12/API-RPC/WinNet
    25-Oct-92  13:43:19
Sb: #15460-Networking under WOW
Fm: John Tarbox 71201,2467
To: Lee Hart [Microsoft] 76150,2536 (X)

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

    Hi Lee. I can tell you that the implimentation of mailslots under NT has
changed, particulary in the area of guaranteed delivery (not availible).

There is 1 Reply.


#: 15761 S12/API-RPC/WinNet
    25-Oct-92  23:50:18
Sb: #15751-Networking under WOW
Fm: Lee Hart [Microsoft] 76150,2536
To: John Tarbox 71201,2467 (X)

>>>- Mailslots

>>>Hi Lee. I can tell you that the implimentation of mailslots under
   NT has changed, particulary in the area of guaranteed delivery
   (not availible).

Hi John,
  Just so that everyone knows exactly what is going on, John is referring to
the fact that First Class Mailslots are no longer available for Win32 apps.
The reason this was done is that First Class Mailslots are basically atomic
Named Pipe operations, and very few developers were actually using them. Since
any code that relied upon First Class Mailslots can be easily converted to use
Named Pipes instead, this should not be an issue for anyone.  If it is, please
pipe up.  (One reason for the demise of First Class Mailslots is the large
amount of broadcasts required to support them).

Lee Microsoft Developer Support

#: 15760 S12/API-RPC/WinNet
    25-Oct-92  22:47:22
Sb: winsock bug?
Fm: Eric Brown 71214,1006
To: ALL (tech support?)

I can't seem to compile the simplest program with #include <winsock.h>. I
don't know what I'm doing wrong. Here's my program, makefile and nmake output:
(I'm compiling with the October '92 Beta 1 release under NT.) socktest.c: ----
 /*
 * socktest.c
 * prove we have errors
 */

#: 15791 S12/API-RPC/WinNet
    26-Oct-92  12:09:15
Sb: #15760-winsock bug?
Fm: David Taniguchi [MS] 72350,2054
To: Eric Brown 71214,1006 (X)

Hi Eric,
  You must include windows.h in your source file.  The simplest Windows
  Sockets program still has to be a Windows program. What I did was take
  generic.c and add "#include <winsock.h>".  Also, in the makefile add a
  "mylibs=$(LIB)\wsock32.lib".  In the link line add $(mylibs) after the
  $(guilibs).
  Let me know if you need more help,
  Dave

#: 15732 S12/API-RPC/WinNet
    24-Oct-92  01:25:14
Sb: RAW IP Support in NT
Fm: Balaji - SynOptics 76330,1047
To: SysOp (X)

Does NT support RAW IP? We need IP and ICMP header information.
Can I retreive this using WINSOCK API? or I need to use the TDI API's?

-Balaji

There is 1 Reply.

#: 15800 S12/API-RPC/WinNet
    26-Oct-92  14:01:28
Sb: #15732-RAW IP Support in NT
Fm: David Taniguchi [MS] 72350,2054
To: Balaji - SynOptics 76330,1047

Hi Balaji,
  You don't have access to RAW sockets using WinSockets.  I believe the
  Windows Socket specifications don't require vendors to support RAW sockets.
  However, ICMP is supported under NT (ping works).
  Hope this helps,
  Dave

#: 15801 S12/API-RPC/WinNet
    26-Oct-92  14:01:32
Sb: #15598-TTY to TELNET
Fm: David Taniguchi [MS] 72350,2054
To: Howard Myers 76711,462

Hi Howard,
  Sorry about the delay.  The sysop has been very busy and hasn't had time
  to upload.  I sent him a note, and it should be up there soon.

  -Dave

#: 15864 S12/API-RPC/WinNet
    27-Oct-92  10:19:18
Sb: RPC
Fm: Bruce Ramsey/Microsoft 70324,2742
To: Koby 71172,2722 (X)

Hi Koby -

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

You're quite right, there is a mismatch here.  Unfortunately this
  mismatch didn't get corrected in the October CD.  We'll correct
  the mismatch in a future build.  Thanks for pointing it out

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

We are still investigating this.  I apologize for the delay

Bruce

#: 15809 S12/API-RPC/WinNet
    26-Oct-92  14:59:56
Sb: RPC name service
Fm: Christian Betrisey 76600,1450
To: Microsoft

I attempt to export a server binding handle to the name service database. The
call I used to do it is as follows:

RpcNsBindingExport (0,0,ServerIfHandle,BindingVec,0);

where, BindingVec is the result of RpcServerInqBindings (). I got the error
status RPC_S_INCOMPLETE_NAME. I guess I have to put something in the first two
args, but I do not know what I should put there. I also would like to know
where you have explanations for the first two args (EntryNameSyntax and
EntryName).

Thanks for your help.

Nick,

#: 15926 S12/API-RPC/WinNet
    27-Oct-92  18:21:25
Sb: #15809-RPC name service
Fm: David Taniguchi [MS] 72350,2054
To: Christian Betrisey 76600,1450 (X)

Hi Nick,
  >> I guess I have to put something in the first two args, but I do not
  know what I should put there. I also would like to know where you have
  explanations for the first two args (EntryNameSyntax and EntryName).

  The first argument (EntryNameSyntax) describes the syntax of the second
  parameter (EntryName).  For example:

    RpcNsBindingExport( RPC_C_NS_SYNTAX_DEFAULT,..)

  Will instruct the system to examine the RPC_DEFAULT_ENTRY_SYNTAX
  environment variable (which most likely is not set).  If this environment
  variable is NOT set, the DCE (rpc_c_ns_syntax_dce) name syntax will be
  used.  (Actually, the environment variable is not looked at in this
  release.  Look at section 1.0 of RPCREAD.ME.  But there are workarounds.)

  A good example to look at would be Auto-handles.  In autos.c, for Entry-
  NameSyntax they use RPC_C_NS_SYNTAX_DEFAULT and for EntryName they use
  "/.:/Autohandle_sample".

  I found this information in Windows Help, page 10 of the Run-Time API
  Reference (The second "book" in the RPC programmer's guide), and
  RPCREAD.ME, which is placed in \mstools\samples\rpc.

  Hope this helps,
  Dave

#: 15752 S12/API-RPC/WinNet
    25-Oct-92  13:43:24
Sb: #15408-Net protocols and NT
Fm: John Tarbox 71201,2467
To: Bruce Ramsey/Microsoft 70324,2742 (X)

    Bruce, could you give me the nickel tour of the differences between NDIS
3.0 and NDIS 2.x?  Thanks.

#: 15866 S12/API-RPC/WinNet
    27-Oct-92  10:19:37
Sb: #15752-Net protocols and NT
Fm: Bruce Ramsey/Microsoft 70324,2742
To: John Tarbox 71201,2467 (X)

Hi John -

>> Bruce, could you give me the nickel tour of the differences
  between NDIS 3.0 and NDIS 2.x?  Thanks.

I'll give it a shot, although I'm probably not the best one for
  this.  If MSWIN32 section 13 isn't open right now, it should be
  open soon.  The DDK conference is this week and we plan to open
  section 13 during the conference.  In any case, section 13 is
  (or will soon be) the place for device driver questions like
  this

I expect you know a fair bit of the below, but rather than leave
  out the parts I'd guess you know, I've included them for the
  benefit of other forum readers

Conceptually, NDIS 3.0 and NDIS 2.x are the same.  They both
  define the upper interface for a network adapter's device
  driver.  They also define the lower interface for a protocol
  stack.  The goal of such a spec is to allow any NDIS protocol
  stack to talk to any NDIS network adapter device driver.  In
  other words, NDIS is the interface that NDIS protocol stacks use
  to talk to NDIS network adapter device drivers

  Needless to say this interchangability is limited to NDIS
    protocol stacks and NDIS network adapter drivers written for a
    particular operating system.  An NDIS network adapter device
    driver for MS-DOS can't run on Windows NT

From an implementation standpoint, moving a device driver
  implemented to the NDIS 2.x spec to being a device driver
  written to the NDIS 3.0 spec is a complete re-code.  I don't
  know of any NDIS 2.x device drivers that are written in C, and
  all NDIS 3.0 device drivers are to be written in C for
  portability across the x86, MIPs, and Alpha platforms

Even, however, if lots of NDIS 2.x network adapter device drivers
  were written in C, rework would still be required by the change,
  because NDIS 2.x network adapter device drivers are written so
  that they rely on operating system facilities directly.  For
  example, NDIS 2.x network adapter device drivers for OS/2 1.x
  are written using DevHelp routines that are provided for use by
  any type of OS/2 1.x device driver


[More]

There is 1 Reply.

#: 15867 S12/API-RPC/WinNet
    27-Oct-92  10:19:43
Sb: #15866-Net protocols and NT
Fm: Bruce Ramsey/Microsoft 70324,2742
To: Bruce Ramsey/Microsoft 70324,2742 (X)

[Continued]

NDIS 3.0 provides the concept of an "NDIS wrapper", so that NDIS
  3.0 network adapter device drivers will not directly use any
  operating system facilities.  Other than using C language and
  the facilities available to them in their hardware (that is, the
  network adapter the device driver drives), each NDIS 3.0 network
  adapter device driver only uses facilities provided to it by the
  NDIS 3.0 wrapper

The benefit is that Microsoft can do the work of porting the NDIS
  wrapper layer to future platforms, and developers of NDIS 3.0
  network adapter device drivers can port their NDIS 3.0 drivers
  to the new platform by recompiling their driver to the ported
  NDIS wrapper

Bruce

#: 15782 S12/API-RPC/WinNet
    26-Oct-92  11:08:39
Sb: #15446-Net protocols and NT
Fm: Paul Kwan 75360,625
To: Todd Needham [Microsoft] 73650,240

Hi Todd,
       I am interested in getting those 2 specs from you too. Here's my
mailing address:

       Paul S. Kwan
       Oris Computer Services,
       153 8th Ave,
       San Francisco, CA 94118

       We are a software development and network consulting company serving
the Bay Area. TIA...

PSK

#: 15871 S12/API-RPC/WinNet
    27-Oct-92  10:37:14
Sb: Net protocols and NT
Fm: Bruce Ramsey/Microsoft 70324,2742
To: Sheldon Fox 70162,3422 (X)

Hi Sheldon (and others) - Section 13 of MSWIN32 is now open.
  There should be a forum announcement to that effect if there
  hasn't been one already.  Note that you'll have to take some
  action with your Compuserve access tool to be able to see this
  section, just as you would have to take an action with your
  access tool any time a section is added to any forum.  As an
  example, if you use Tapcis you will have to do an Alt-J on
  MSWIN32 again to re-join the forum in order to see section 13,
  and prior to doing the alt-J you have to edit the list of
  desired sections to ensure it includes 13

Again, I apologize for my error and the errors others at Microsoft
  made when we previously said section 13 was open, or referred
  people to it when it was in fact not yet public

As a side note, MSWIN32 section 14 on Win32S specific questions
  is also now open

Bruce



There is 1 Reply.

#: 15939 S12/API-RPC/WinNet
    27-Oct-92  20:16:38
Sb: #15871-Net protocols and NT
Fm: Sheldon Fox 70162,3422
To: Bruce Ramsey/Microsoft 70324,2742 (X)

Bruce,

Thanks!  /Sheldon

#: 15741 S12/API-RPC/WinNet
    25-Oct-92  00:08:00
Sb: #15062-Re: Win RPC / UNIX RPC
Fm: gene saunders 72265,23
To: Bruce Ramsey/Microsoft 70324,2742 (X)



It was my understanding that the DCE RPC spec is not yet implemented by any
Unix vendors.  Can that be true?  If so, then what can I connect to for
testing?  Why no support for ONC RPC, since there's a lot of that out there?
Doesn't Novell support the ONC form?

#: 15999 S12/API-RPC/WinNet
    28-Oct-92  15:58:09
Sb: #15741-Re: Win RPC / UNIX RPC
Fm: Bruce Ramsey/Microsoft 70324,2742
To: gene saunders 72265,23

Hi Gene -

>> It was my understanding that the DCE RPC spec is not yet
  implemented by any Unix vendors.  Can that be true?  If so, then
  what can I connect to for testing?  Why no support for ONC RPC,
  since there's a lot of that out there?  ...

We aren't planning to support ONC RPC -- we support DCE RPC to
  UNIX systems.  We expect ONC RPC will be available from third
  parties

I'm checking with the OSF (Open Software Foundatation) to see if
  they can provide a list of Unix vendors that currently offer
  implementations of DCE RPC

Bruce

#: 16041 S12/API-RPC/WinNet
    29-Oct-92  00:25:12
Sb: NT SERVICES
Fm: D. Le Roux & Associates 70142,3507
To: Bruce Ramsey 70324,2742 (X)

We would like to know if the Win32 services API is fully implement in the July
92 release of NT since we cannot find the documented functions in the lib's
eg. OpenSCManager
Thanks

There is 1 Reply.

#: 16069 S12/API-RPC/WinNet
    29-Oct-92  08:49:22
Sb: #16041-NT SERVICES
Fm: Bruce Ramsey/Microsoft 70324,2742
To: D. Le Roux & Associates 70142,3507

Hi -

>> We would like to know if the Win32 services API is fully
  implement in the July 92 release of NT since we cannot find the
  documented functions in the lib's eg.  OpenSCManager

The services API unfortunately didn't make it into the July
  release any further that the help files.  In the October release
  they're all the way there.  I apologize for any inconvenience
  resulting from this.  You should, if you haven't already, soon
  receive your October update

Bruce

#: 16049 S12/API-RPC/WinNet
    29-Oct-92  05:31:50
Sb: Adaptor Support under NT
Fm: Centre File 100015,3565
To: all



We are developing server applications using NT and will quite likely require
many simultaneous connections to that server.

Is Lanman for NT likely to have support for multiple addapters?  If so, will
there be any impact on our useage of Named Pipes?

Does anybody have any idea of what the connection limit will be?


Kaz Librowski  Centrefile

There is 1 Reply.

#: 16078 S12/API-RPC/WinNet
    29-Oct-92  10:46:51
Sb: #16049-Adaptor Support under NT
Fm: Bruce Ramsey/Microsoft 70324,2742
To: Centre File 100015,3565

Hi Kaz -

>> We are developing server applications using NT and will quite
  likely require many simultaneous connections to that server

It's highly likely any such app will run out of resources such as
  cpu cycles, io capacity, etc, before running out of named pipes
  connections.  The limit is not exactly, but very close to, 2**32

>> Is Lanman for NT likely to have support for multiple addapters?

Yes, the support is in both the July and October releases, and
  will be in the future release

>> If so, will there be any impact on our useage of Named Pipes?

I don't believe adding more another net card will change the limit
  from being close to 2**32.  OTOH, adding another net card may
  increase system through-put if the network adapter is a limiting
  performance factor.  Whether the net adapter is a limiting
  performance factor varies a lot depending on network adapter
  used, bus type, and lots of other factors including application
  issues

>> Does anybody have any idea of what the connection limit will
  be?

We'll be publishing exact system limits on things like this as
  soon as we can draw up the list, but it may unfortunately be
  several months before the list is ready.  OTOH, as I mentioned
  above, this limit will be close to 2**32, so in practice this
  limit won't be the gating factor for the foreseeable future

You may not be interested in this next note, but I'll include it
  anyway for the benefit of other forum readers.  NetBIOS apps are
  still limited in the number of sessions they can support.  This
  is due to compatability needed with the existing definition of
  the NCB data structure.  If you have the July or October CD for
  developers, see \mstools\h\nb30.h, line 42 (in October CD
  anyway) where ncb_lsn is defined as a one byte field

We can't change that from one byte, so NetBios apps are going to
  have the same close-to-2**8 limits they've always had.  This is
  one good reason to move high-capacity apps to named pipes or
  RPC.  When RPC or named pipes ride on top of NetBIOS as an

[More]

There is 1 Reply.

#: 16079 S12/API-RPC/WinNet
    29-Oct-92  10:46:57
Sb: #16078-Adaptor Support under NT
Fm: Bruce Ramsey/Microsoft 70324,2742
To: Bruce Ramsey/Microsoft 70324,2742 (X)

[Continued]

  underlying transport, we do all the work of multiplexing named
  pipes (or RPC) sessions on top of fewer NetBIOS sessions

This multiplexing is work NetBIOS app developers could choose to
  do for themselves if they wished to have a higher capacity
  NetBIOS app and still be using NetBIOS rather that named pipes
  or RPC.  I would caution, however, that the amount of work is
  not trivial to produce a fast general solution.  And of course,
  even when done, the model the app uses is still the NetBIOS
  model.  I would suggest that before undertaking to work like a
  fiend to expand NetBIOS capacity by doing the multiplexing
  oneself, one would want to take a look at the other advantages
  offered by the named pipes and RPC models

Bruce

#: 15862 S12/API-RPC/WinNet
    27-Oct-92  10:08:00
Sb: Win16 Netbios problem
Fm: Michael Lynch 76260,1670
To: SYSOP (X)

I am trying to operate several Windows 16-bit apps which use Netbios to
communicate with other programs. These apps appear to start up but always exit
without warning after 3 seconds of life. The autoexec and config files
 appear to have the REDIR and DOSX lines in them. The network is fully
installed as near as I can tell. I have added the TCP/IP support, and can
access network disks over both Netbeui and TCP/IP. Protocol.INI looks like it
does for my Windows For Workgroups version, so it looks ok... I am running the
October Beta of /NT. I did not have any luck for different
 reasons trying to run these apps in the 1st Beta. Can you give me some
direction as to where to look for my problem? These apps work fine in both
Win3.1 and WFW3.1 on the same machine. Thanks Mike

There is 1 Reply.

#: 16108 S12/API-RPC/WinNet
    29-Oct-92  13:32:41
Sb: #15862-Win16 Netbios problem
Fm: Bruce Ramsey/Microsoft 70324,2742
To: Michael Lynch 76260,1670

Hi Mike  -

>> I am trying to operate several Windows 16-bit apps which use
  Netbios to communicate with other programs.  These apps appear
  to start up but always exit without warning after 3 seconds of
  life.  The autoexec and config files appear to have the REDIR
  and DOSX lines in them.  The network is fully installed as near
  as I can tell.  I have added the TCP/IP support, and can access
  network disks over both Netbeui and TCP/IP.  Protocol.INI looks
  like it does for my Windows For Workgroups version, so it looks
  ok...  I am running the October Beta of /NT.  I did not have any
  luck for different reasons trying to run these apps in the 1st
  Beta.  Can you give me some direction as to where to look for my
  problem?  These apps work fine in both Win3.1 and WFW3.1 on the
  same machine

The methods you may be used to using to debug 16-bit apps for
  Windows may not work for you in the October build.  So, you may
  have to resort to adding some printf statments in various places
  where the app may be after about 3 seconds, to log to a file how
  far the app got successfully.  After a few iterations of putting
  in printf statements, rebuilding and retrying, the log should
  show where the app is when the October build is failing

Another test you could try (if you haven't already) is to remove
  TCP/IP to see if it's presence on the system is at all related

We've tried a number of 16-bit named pipes and netbios apps on the
  October build and they work, but that doesn't mean there aren't
  any remaining problems in this area.  We appreciate any further
  info you can provide regarding the apps that don't work for you
  so we can work on correcting any remaining problems.  Thanks!

Bruce

#: 16087 S12/API-RPC/WinNet
    29-Oct-92  11:24:43
Sb: Promiscuous Rcv
Fm: Christian Beaumont 100034,2326
To: All

I am working on a tool for MIS managers to show network load, contents of
packets, average packet size, most active machines on a net. For this I rely
on having a network card that supports promiscuous receive mode and up until
recently the clarkson packet drivers. Am I correct that in order to do this
under NT I will require the DDK and an understanding of the NDIS 3.0 spec?

Thanks in advance. Christian Beaumont

There is 1 Reply.

#: 16107 S12/API-RPC/WinNet
    29-Oct-92  13:32:30
Sb: #16087-Promiscuous Rcv
Fm: Bruce Ramsey/Microsoft 70324,2742
To: Christian Beaumont 100034,2326 (X)

Hi Christian -

>> I am working on a tool for MIS managers to show network load,
  contents of packets, average packet size, most active machines
  on a net.  For this I rely on having a network card that
  supports promiscuous receive mode and up until recently the
  clarkson packet drivers.  Am I correct that in order to do this
  under NT I will require the DDK and an understanding of the NDIS
  3.0 spec?

I'm not familiar with the clarkson packet drivers, however it does
  sound like these drivers will need to be ported to Windows NT,
  or equivalent drivers written, and you're correct that the DDK
  and NDIS 3.0 will be needed for this.  I use the word port here
  loosely, as most existing network adapter drivers are written in
  .asm, and all NDIS 3.0 drivers are written in C

It also sounds like the Win32 Preliminary SDK for Windows NT will
  also be needed for some of the other parts of the tool - this
  may be obvious to you, but for the benefit of other forum
  readers I thought I'd risk belaboring the obvious :), and point
  out that apps like this that need both a device driver component
  and a Win32 app component will need both development kits

The DDK can be ordered via a coupon on page 16 of vol 1 num 2 of
  the Microsoft Developer's Network Newsletter, or as that issue
  mentions on page 10, you can call 800-227-4679 ext 11771

Section 13 of MSWIN32 is now open for DDK questions, so if you
  have more questions on NDIS 3.0, device drivers for network
  adapters, etc, that's where the people who are most focussed on
  those issue are

Bruce



There is 1 Reply.

#: 16173 S12/API-RPC/WinNet
    30-Oct-92  03:07:00
Sb: #16107-Promiscuous Rcv
Fm: Christian Beaumont 100034,2326
To: Bruce Ramsey/Microsoft 70324,2742 (X)

Thanks for the speedy response Bruce. Chris

#: 16055 S12/API-RPC/WinNet
    29-Oct-92  06:45:12
Sb: How do I get user list?
Fm: Bob Byron 70107,1734
To: All


Regarding NT, I was wondering how, via the API, I would go about getting a
list of users that are logged in to a network.  I guess I would start with my
system, and want to get the name of the user logged in to it.  I guess I
would also need to know what other systems are on the network and get the name
of the user on each of those systems.  But, what are the calls involved?
Also, is there a way to find out what systems are on the network?  Or, do I
have to know that ahead of time.  These are probably more general questions,
but I am just learning this stuff.

Thanks, Bob


By the way, if this is not the write area for this question, please move this
note to the appropriate place.

There is 1 Reply.

#: 16088 S12/API-RPC/WinNet
    29-Oct-92  11:53:24
Sb: #16055-How do I get user list?
Fm: David Taniguchi [MS] 72350,2054
To: Bob Byron 70107,1734 (X)

Hi Bob,
  Currently with the SDK there is nothing which will allow you to get the
  names of the users.  We are checking into making this information
  available to the programmer.
  Thanks,
  Dave



There is 1 Reply.

#: 16183 S12/API-RPC/WinNet
    30-Oct-92  07:39:10
Sb: #16088-How do I get user list?
Fm: Bob Byron 70107,1734
To: David Taniguchi [MS] 72350,2054 (X)

Thank you for your reply, although I was hoping for a more favorable answer.
How about getting the list of nodes attached to the network?  Seems to me, if
I can get a node list of all the nodes on the network, that would be a good
start.  Then if I got the user on that system...  Are you saying I cannot even
query the machine I am on for the user logged in?  Also, am I logged in to the
"console"?  Is "console" the write term you have assigned to the keyboard and
monitor?

By the way, what is WinNet responsible for then?  I assume pier to pier file
io, but what else?

If you would, I would hope you will answer every question please.

Thanks, Bob Byron

There is 1 Reply.

#: 16204 S12/API-RPC/WinNet
    30-Oct-92  11:54:13
Sb: #16183-How do I get user list?
Fm: David Taniguchi [MS] 72350,2054
To: Bob Byron 70107,1734 (X)

Hi Bob,
  Since it's a relatively short list, let me list the API and a brief
  description of what it does.  All these API are provided in the SDK.

  WNetAddConnection() - Connect to network resource (disk, printer)
  WNetCancelConnectio() - Break an existing network connection.
  WNetOpenEnum() - Starts enumeration of network resources.
  WNetCloseEnum() - ends a network resource enumeration
  WNetConnectionDialog() - Starts a general browsing dialog
  WNetGetUser() - Retrieves the current default user name or the user
    name used to establish a network connection.


  >How about getting the list of nodes attached to the network?

  You can enumerate all the NT machines and what resources they have
  available on the network.

  >You can enumerate Seems to me, if I can get a node list of all the nodes
  >on the network, that would be a good start.  Then if I got the user on
  >that system...  Are you saying I cannot even query the machine I am on for
  >the user logged in?

  WNetGetUser() provides the user that's currently logged on.

  >Also, am I logged in to the "console"?  Is "console" the write term
  >you have assigned to the keyboard and monitor?

  I would say logged in to MACHINENAME.  This seems more appropriate (IMHO).
  Even more descriptive would be logged into MACHINENAME on the DOMAINNAME
  domain.

  >By the way, what is WinNet responsible for then?  I assume pier to pier
  >file io, but what else?

  I assume you mean the WNet prefixed API.  These are network independent
  functions to add and cancel network connections and to retrieve info.
  about the current configuration of the network. (from winhelp)

  If you happen to have the SDK, bring up the Win32 API Reference, and
  browse through the networks overview and related topics.  This explains
  what capabilities are present.

  If you have more questions, feel free to post,
  Dave

#: 16099 S12/API-RPC/WinNet
    29-Oct-92  13:28:02
Sb: network registry access
Fm: Andrew Potter 71075,614
To: all


I have several related questions as to how the NT registry might be used to
manage information accross the network.

Can the Registry provide shared user id information?  Can the Registry be
queried for information across the network?  Is the information provided by
the registry distributed to all the machines?

What tools are provided to interface with the Registry?

Thanks,

Andrew



There is 1 Reply.

#: 16136 S12/API-RPC/WinNet
    29-Oct-92  16:41:04
Sb: #16099-network registry access
Fm: Bruce Ramsey/Microsoft 70324,2742
To: Andrew Potter 71075,614 (X)

Hi Andrew  -

>> I have several related questions as to how the NT registry
  might be used to manage information accross the network

From the questions I'm unsure whether you're asking about managing
  user account/password/group info, or something else

Special tools for managing user account/password/group info across
  the net are included in LAN Manager for Windows NT

>> Can the Registry provide shared user id information?

When LAN Manager for Windows NT is employed, yes.  Otherwise, I
  don't think so, but it may depend on what you're after.  If this
  response doesn't answer what you're asking, please ask again

>> Can the Registry be queried for information across the network?

Yes, please see the RegConnectRegistry api in the Win32 api help
  files

>> Is the information provided by the registry distributed to all
  the machines?

No, not in the general case.  LAN Manager for Windows NT adds the
  concept of domains, and manages user account/password/group info
  across an entire domain.  Primary Domain Controllers and Backup
  Domain Controllers in a domain take part in a process
  automatically managed by LAN Manager for Windows NT where all
  the user account/password/group info for the domain is
  replicated among the PDC and all BDCs

>> What tools are provided to interface with the Registry?

Please see the Registry and Initialization files Overview in the
  Win32 help files, and also see the list of Regxxxxx api's in the
  Win32 help file

Bruce



There is 1 Reply.

#: 16219 S12/API-RPC/WinNet
    30-Oct-92  14:13:48
Sb: #16136-network registry access
Fm: Andrew Potter 71075,614
To: Bruce Ramsey/Microsoft 70324,2742 (X)


Thanks, Bruce.  One more question. If LANManager can administer user account
information, can it be used to manage other user defined information? For
example, project_A's design files are located on server_A_proj under the
/proj_A file system and project_A's database is located on server_DB_A_proj
under the /proj_A file system. If LANManager cannot do the above example, can
the registry provide the above information?

  Andrew

#: 15865 S12/API-RPC/WinNet
    27-Oct-92  10:19:24
Sb: #15719-RPC nesting alls
Fm: Bruce Ramsey/Microsoft 70324,2742
To: Koby 71172,2722 (X)

Hi Koby -

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

You're quite right, there is a mismatch here.  Unfortunately this
  mismatch didn't get corrected in the October CD.  We'll correct
  the mismatch in a future build.  Thanks for pointing it out

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

We are still investigating this.  I apologize for the delay

Bruce

#: 16251 S12/API-RPC/WinNet
    30-Oct-92  18:55:44
Sb: #15719-RPC nesting alls
Fm: Bruce Ramsey/Microsoft 70324,2742
To: Koby 71172,2722

Hi Koby - Regarding the nesting of RPC calls, or rather the having
  A call B.bar and B call A.foo, first, I apologize for the delay
  responding.  I further apologize because I don't yet have a
  complete answer for you

I did get A calling B.bar and B calling A.foo to a depth of
  several times, however this is a preliminary result.  The basic
  calls seem to work, but yet not everything.  I still need to
  clean up the sample and test it on different protocol sequences

Item 25 in the file on the October CD
  \mstools\samples\rpc\rpcread.me indicates this won't work in the
  October build using netbios, so I don't expect to get this to
  work with all protocol sequences on the October build

The first version of the test program I tried failed after one
  call each of A.foo and B.bar, due to the binding handles for
  both processes (needed to make calls to the remote procedures)
  not having been established yet.  Adding critical sections
  (other synchronization methods would also work) to ensure that
  the needed binding handles were ready before making calls
  relying on the binding handles was necessary in my test case to
  get past this hurdle

You're probably already well aware of this, but I'll mention it
  anyway for the benefit of other forum readers

A.foo calling B.bar where B.bar is a remote procedure, then having
  B.bar call A.foo where A.foo is also a remote procedure, differs
  from having foo and bar be mutually recursive procedures in the
  same thread in a single process.  Of course it differs :-), in
  several ways, but two things in particular to bear in mind are
  the thread and stack differences

  In the mutually recursive case where both A.foo and B.Bar are in
    the same thread in the same process, another recursive call to
    either function doesn't spawn a thread.  But when they are
    each remote procedure calls, every additional call spawns a
    thread in the serving RPC process to service the remote call

  Then of course, the thread spawned has it's own stack.  Which
    differs from the mutually recursive case where both A.foo and

[More]

There is 1 Reply.

#: 16252 S12/API-RPC/WinNet
    30-Oct-92  18:55:51
Sb: #16251-RPC nesting alls
Fm: Bruce Ramsey/Microsoft 70324,2742
To: Bruce Ramsey/Microsoft 70324,2742 (X)

[Continued]

    B.Bar are in the same thread in the same process:  in that
    case there's only one stack

I'll post more info from further work with the test case as soon
  as I can

Bruce




#: 15892 S13/Windows NT DDK
    27-Oct-92  15:15:32
Sb: #15564-AT DMA and HAL
Fm: Paul Sanders [Microsoft] 72350,2053
To: Michael Hall 72607,3422

Clay,
   I'm not going to do anything about your HalReadDmaCounter until after you
have tested it on the latest DDK.  If it is still a problem with the new DDK,
let me know and I will bug it.

Thanks,

Paul Sanders, Microsoft


#: 16011 S13/Windows NT DDK
    28-Oct-92  17:45:43
Sb: KD won't show local Symb
Fm: Jim Harford 72350,3705
To: All

I am using the July SDK/DDK and am unable to get the Kernel Debugger
to display local symbols using the "." command as indicated in its
help screen.  I have also attempted to get the compiler to use the /ZI option
by setting NTDEBUG=ntsd.  Can you tell me what I am doing wrong?

#: 15980 S13/Windows NT DDK
    28-Oct-92  13:06:19
Sb: Kernel Debugger question
Fm: Michel J. Tremblay 72360,132
To: Michel J. Tremblay, 72360,132 (X)

Hi

This is a question about the Kernel debugger. How do I get symbolic
information for the driver I want to debug ? It looks like the debugger gives
me symbolic information about ntoskrnl.exe only. If I invoke the debugger with
  i386kd -v \path\mydriver.exe \path\ntoskrnl.exe I cannot get symbolic
information for my driver.

Michel

There is 1 Reply.

#: 16064 S13/Windows NT DDK
    29-Oct-92  08:09:52
Sb: #15980-Kernel Debugger question
Fm: Paul Sanders [Microsoft] 72350,2053
To: Michel J. Tremblay 72360,132 (X)

Michael,
    The directory that the kernel debugger searches for symbols is hard coded,
unfortunately.  It's not a major problem though.  All you have to do is set
the environment variable, _NT_SYMBOL_PATH, and then make the following
directories, ..\nt\system\drivers

    So, for example :

set _NT_SYMBOL_PATH=e:\debug

    Then copy your drivers to e:\debug\nt\system\drivers.  Also, copy HAL.DLL,
NTDLL.DLL and NTOSKRNL.EXE to e:\debug\nt\system.

    Then invoke the kernel debugger with :

i386kd -v e:\debug\nt\system\ntoskrnl.exe

This should allow you to access your driver symbols.

Paul Sanders, Microsoft

#: 15936 S13/Windows NT DDK
    27-Oct-92  19:21:15
Sb: Editor setup
Fm: jon behrens 71302,3023
To: sysop (X)

I have just gotten my mswin32 sdk and am having a bit of trouble gettint
things set up properly. I am new to pc's (I come from UNIX), so please give me
help in simple terms. I have a 486 with a non scsi cdrom and a reasonable
amount of memory and hard disk. If there is an archive of frequently asked
quesitons about setup, that would be very helpful. My immediate question
concerns the editor MEP. Mine comes up with a black window and no menu bar.
Further, it does not respond to any of the key cords described in the file
tools.ini. Changing the tools.ini file per the instructions has no effect on
either the appearance or the function of the editor. What am I missing? Thank
you for the help...
 Jon

There are 2 Replies.

#: 15974 S13/Windows NT DDK
    28-Oct-92  11:45:53
Sb: #15936-Editor setup
Fm: Dan Knudson [Microsoft] 72350,2055
To: jon behrens 71302,3023 (X)

<<My immediate question concerns the editor MEP. Mine comes up with a black
window and no menu bar. Further, it does not respond to any of the key cords
described in the file tools.ini. Changing the tools.ini file per the
instructions has no effect on either the appearance or the function of the
editor.>>

mep looks for tools.ini to be in the directory pointed at by the "init"
environment variable. if you go to the command line & type "set init=c:\init"
(or whatever directory your tools.ini resides in) then invoke mep, it will be
able to find tools.ini & make the appropriate key bindings. the "set" command
i mentioned will only set the environment for the particular command prompt
instance; to set this variable value system-wide (for the current user) go to
the control panel & start the "System" applet & add/change the variable(s).

i'm not sure about the faq status, but your opsys install questions will be
best answered in WINNT, where MSWIN32 focuses on sdk & ddk (developeroriented)
issues.

dan

#: 16048 S13/Windows NT DDK
    29-Oct-92  05:03:01
Sb: #15936-Editor setup
Fm: Al Longyear 70165,725
To: jon behrens 71302,3023 (X)

Since you came from UNIX, there is an EMACS clone editor called MicroEmacs in
the download libraries. You might find it more compatable to your brain than
Microsoft's older C version 4 style editor. (Just though that I'd mention it.)

There is 1 Reply.

#: 16070 S13/Windows NT DDK
    29-Oct-92  08:57:28
Sb: #16048-Editor setup
Fm: jon behrens 71302,3023
To: Al Longyear 70165,725 (X)

Thank you both for the help. Jon

#: 16131 S13/Windows NT DDK
    29-Oct-92  15:39:00
Sb: Device IO control for NT
Fm: Robert Strickler 71160,2462
To: ALL

I know this is a shtupid question, nevertheless here we go. Given a scsi
toaster device driver which has a browning control whose value is get/put by
the drivers' public control code

#: 16032 S13/Windows NT DDK
    28-Oct-92  20:16:18
Sb: Open SCSI w/CreateFile()
Fm: Jim Gill 70530,1771
To: Paul Sanders 72350,2053 (X)

Howdy.

I'm wanting to send a DeviceIOControl ioctl (a cdb not otherwise supported by
the standard calls) to my SCSI hard disk.  I've read the thread about the port
driver making a name available with IOAssignArcName() but since source for the
SCSI port driver isn't on my DDK disk I don't know what name was assigned.

For sake of this message assume my drive is the one and only SCSI unit on the
one and only SCSI adapter (a Future Domain 1660 tho this shouldn't matter), at
ID 0/LUN 0.

Two questions:

(1) What name (in the form I would pass to CreateFile()) will be assigned to
this unit?  For example, the IDE hard disk driver seems to make names like
"\ArcName\multi(0)disk(0)rdisk(0)", how much of this gets passed to
CreateFile()?  The "arcname" part might not be right, don't let this throw
you.

(2) Are there any special access flags I mustn't forget when I call
CreateFile()?



There is 1 Reply.

#: 16100 S13/Windows NT DDK
    29-Oct-92  13:29:01
Sb: #16032-Open SCSI w/CreateFile()
Fm: Paul Sanders [Microsoft] 72350,2053
To: Jim Gill 70530,1771 (X)

Jim,
    SCSI miniport drivers are not designed for an IOCtl interface.  If you
want to use a unique CDB, I believe you will have to install a filter driver.
You should have your new DDK by now (if not, then very soon).  Look at the
code for CDAUDIO.  This is a filter driver that converts SCSI-II audio
commands to SCSI-I commands that are equivalent for a few select CD players.

    I know I have glossed over this, but examine the CDAUDIO code and also
review the documentation about filter drivers.

Let me know if you need more information,

Paul Sanders, Microsoft




There is 1 Reply.

#: 16165 S13/Windows NT DDK
    29-Oct-92  21:48:42
Sb: #16100-Open SCSI w/CreateFile()
Fm: Jim Gill 70530,1771
To: Paul Sanders [Microsoft] 72350,2053 (X)

Paul, thanks for the quick response.  I'm sorry but I need a little more info
(well, actually, I'm just hoping for *different* info :-) )

I think you're right about miniport drivers.  Luckily, I believe I'm supposed
to send the request to the SCSI class driver, or possibly the port driver.
But I haven't been able to find their names, either.

Section B.4.5 of my DDK guide documents IRP_MJ_DEVICE_CONTROL, and says this
can be reached when "a Win32 application has called DeviceIoControl, or a
higher-level driver has set up such a request."

Then table B-20 documents IOCTL_PASS_THROUGH for the SCSI port driver.  The
part I don't quite follow is where the description goes "The application must
specify either the target device if it is controlled by a class driver (and
this IOCTL must be directed to the class driver), or the application must
specify the target logical unit if no class driver 'owns' the device (and this
IOCTL must be directed to the port driver)."

I figure the SCSI class driver "owns" SCSI hard disks, maybe leaving weird
devices like a SCSI toaster at the port driver level.  The pass-thru struct
lets structure lets my app specify path/target/lun info and CDB.

Could you ask your sources about opening the SCSI class driver from
CreateFile()?  Thanks in advance.

#: 16174 S13/Windows NT DDK
    30-Oct-92  03:13:27
Sb: Promiscuous RX Stack?
Fm: Christian Beaumont 100034,2326
To: All

Hi, this is a continuation of something I posted in the Net section.

I need to do promiscuous receive (assuming the hardware can do it) from the
ether card. Is it possible to add such a stack to NDIS 3.0 easily? I am
currently awaiting my DDK CD and hope that I might find something on there to
help me - am I right?

Christian Beaumont

#: 16192 S13/Windows NT DDK
    30-Oct-92  09:46:27
Sb: Updating from July DDK
Fm: Robert Strickler 71160,2462
To: SYSOP (X)

What do we need to do to update from our july DDK to the new october release?

#: 15798 S13/Windows NT DDK
    26-Oct-92  13:57:48
Sb: #15688-Miniport Ques
Fm: Paul Sanders [Microsoft] 72350,2053
To: Bob Roycroft 71431,3206

Bob,
   I agree, the NumberOfAccessRanges variable is confusing.  This will
hopefully be clarified in future documentation.  The value for
NumberOfAccessRanges will be either a 1 or a 2.  If you use only memory
addresses then the value is 1.  If you use only I/O adrresses, then the value
is also 1.  If you use both memory and I/O addresses, then the value is 2.

I hope this helps to clarify this,

Paul Sanders, Microsoft

#: 15891 S13/Windows NT DDK
    27-Oct-92  15:15:27
Sb: #15687-Miniport Ques
Fm: Paul Sanders [Microsoft] 72350,2053
To: Bob Roycroft 71431,3206

Bob,
    I've been researching this for you.  At this point, I don't have an
answer.  I was not able to readily answer this by grepping through the source
code.  I have some outstanding email that I am waiting for. Unfortunately,
almost everyone is at the conference.  I will get back with you as soon as I
find out more.

Thanks for your patience,

Paul Sanders, Microsoft

#: 16195 S13/Windows NT DDK
    30-Oct-92  10:50:56
Sb: #15687-Miniport Ques
Fm: Paul Sanders [Microsoft] 72350,2053
To: Bob Roycroft 71431,3206

Bob,

The flags in the CDB do not do the same thing as the flags in the SRB. The
flags in the SRB apply to the SCSI adapter; the flags in CDB apply to the
target device.  The FUA bit is set when necessary if the device indicates that
the write caching is enabled.  The flag in the SRB is set when necessary if
the adapter caching bit is set.  Note NT does not use DPO.

Hope this helps,

Paul Sanders, Microsoft

#: 15906 S13/Windows NT DDK
    27-Oct-92  15:59:47
Sb: #15713-October Beta and 8514 ??
Fm: Charles F. McDevitt 70302,2374
To: Dan Knudson [Microsoft] 72350,2055 (X)

C'mon guys, I know you and IBM are constantly fighting, so 8514A
drivers seem like they should be done "as late as possible",
but in reality there are LOTS of us out here with ATI Graphics
Ultra boards that are 8514 compatible, and we need drivers!!!


There are 3 Replies.

#: 15912 S13/Windows NT DDK
    27-Oct-92  17:08:01
Sb: #15906-October Beta and 8514 ??
Fm: Muzaffer KAL [MSC] 70324,2553
To: Charles F. McDevitt 70302,2374

it's nothing to do with that. they have XGA drivers already. I think ATI is
dragging its feet.

Muzaffer

#: 16037 S13/Windows NT DDK
    28-Oct-92  22:37:23
Sb: #15906-October Beta and 8514 ??
Fm: Tony Harris 100010,1360
To: Charles F. McDevitt 70302,2374

Are these boards compatible at the hardware level or do they use a software
8514 "look-alike" ram resident driver?

If they are compatible at the hardware level please send me a telephone number
so I can order one.

Regards

Tony Harris

There is 1 Reply.

#: 16077 S13/Windows NT DDK
    29-Oct-92  10:46:50
Sb: #16037-October Beta and 8514 ??
Fm: David Edge 75170,1461
To: Tony Harris 100010,1360

The ATI boards are hardware level compatible.  You can use the IBM 8514 driver
in Windows 3.1 with them.  Look in a PC Magazine, or other to find the phone
number of ATI - I don't have it here.  They have two versions, the 8514 Ultra
and the Graphics Ultra.  The 8514 Ultra requires a VGA card.  This is nice for
Win 3.1 development because codeview can use the VGA for 50 line color
debugging output.  The Graphics Ultra combines the VGA onto the board but only
provides one connector so you don't get dual monitor support.

#: 16221 S13/Windows NT DDK
    30-Oct-92  15:02:36
Sb: #15906-October Beta and 8514 ??
Fm: Frank Guenther 72360,2752
To: Charles F. McDevitt 70302,2374

Here Here! The new ATI VESA local bus cards are sizzling hot!
They also will support 8514 in reg. compatible mode!
The old ATI Ultras have been the Win3x ticket for over a year now,
and no support even for the built-in VGA Wonder.

#: 16238 S13/Windows NT DDK
    30-Oct-92  16:49:32
Sb: DDK Rollout
Fm: Steve Mastrianni [PSS] 71501,1652
To: MS

Let me be the first to thank Microsoft for a bang-up DDK rollout in LA. The
beach party was a "don't miss" event, and the technical content was just
great. If you didn't go, you missed a good one. Only one hour or so of
marketing hype, and the rest was pure technical stuff. Worth the trip.

--Steve




#: 15738 S14/Win32s Specific
    24-Oct-92  14:42:24
Sb: GDI in Win32s
Fm: Wim Bonner 72561,3135
To: microsoft

I've read the bit in my july SDK CDrom about Win32s, but I couldn't quite
figure out what I needed to know about Win32s.

Will I be able to use the 32 bit wide GDI interface, and run under Win32s, or
will I have to run under Win32?  I'm just using functions that were available
under 3.1, but I am using 32 bit coordinates.

Wim

There are 2 Replies.


#: 15759 S14/Win32s Specific
    25-Oct-92  22:00:08
Sb: #15738-GDI in Win32s
Fm: Lee Hart [Microsoft] 76150,2536
To: Wim Bonner 72561,3135

>>>Will I be able to use the 32 bit wide GDI interface, and run under Win32s,
   or will I have to run under Win32?  I'm just using functions that were
   available under 3.1, but I am using 32 bit coordinates.

A good rule of thumb is that if the function you are using is available in
both 16 and 32 bit forms, it is fully supported under Win32s.  For all other
functions, you will still dynalink properly, but calls to those APIs will
return an appropriate error code.  So as long as you restrict your GDI usage
to those APIs available in Windows 3.1, you will work in Win32s under Windows
3.1 as well as in Windows NT.  If you come across any API where this is not
the case, please be sure to report it here so that it can either be fully
documented, or fixed, as the case may be.

Lee Microsoft Developer Support

#: 15797 S14/Win32s Specific
    26-Oct-92  13:56:23
Sb: #15738-GDI in Win32s
Fm: Lee Hart [Microsoft] 76150,2536
To: Wim Bonner 72561,3135

>>>Will I be able to use the 32 bit wide GDI interface, and run under
   Win32s, or will I have to run under Win32?  I'm just using functions
   that were available under 3.1, but I am using 32 bit coordinates.

As stated in the Win32s release notes, you will need to constrain yourself to
16 bit coordinates.

Lee

#: 15890 S14/Win32s Specific
    27-Oct-92  14:33:55
Sb: Win32s (help)
Fm: Robert Zeff 70323,1251
To: All

Am I to assume that the the win32s\floppy could be copied to a floppy and
installed (as a test) on a Win3.1 system.  (Doesn't work for me) Where are the
docs?

Thanks,

-Robert




There is 1 Reply.

#: 15917 S14/Win32s Specific
    27-Oct-92  18:14:26
Sb: #15890-Win32s (help)
Fm: Lee Hart [Microsoft] 76150,2536
To: Robert Zeff 70323,1251 (X)

>Am I to assume that the the win32s\floppy could be copied to a floppy and
>installed (as a test) on a Win3.1 system.  (Doesn't work for me) Where are
the >docs?

You should have recieved, along with your new CD, October Release Notes, a new
HCL, and a Win32s Programmer's Reference.  Page 3 of the Win32s Programmer's
Reference documents how to setup the floppy.

Lee Microsoft Developer Support

#: 15858 S14/Win32s Specific
    27-Oct-92  08:27:53
Sb: U. Thunks Now
Fm: richard c. allen 71621,2420
To: all

The need for 32 Bit and 16 bits apps to communicate is essential. The
Universal Thunk Proposal is fine, but I would like to be trying it out. The
earlier some code can be made available to play with, the sooner the
ramifications will be aparent.

Cheers Richard C. Allen

There is 1 Reply.

#: 15886 S14/Win32s Specific
    27-Oct-92  13:19:34
Sb: #15858-U. Thunks Now
Fm: Lee Hart [Microsoft] 76150,2536
To: richard c. allen 71621,2420 (X)

As mentioned in the release notes, the Universal Thunks are not available yet.
At this time I do not have any information on when they will be available, but
I am looking into it.  Does the design proposal in the Win32s Programmer's
Reference look good to you?

Lee Microsoft Developer Support




There is 1 Reply.

#: 15949 S14/Win32s Specific
    28-Oct-92  05:54:23
Sb: #15886-U. Thunks Now
Fm: richard c. allen 71621,2420
To: Lee Hart [Microsoft] 76150,2536 (X)

The first look seems fine, I don't really like the idea that a 16-DLL needs 2
new functions (UT16Init and UT16Proc) since no DLL's out there has them.
Appears that to use existing DLL's a thin layer will be repuired by me to
provide these Procedures. If the layer is necessary and all "normal" dll's
require the layer, help define the layer cleanly (Tools, demos, etc.) Perhaps
a RPC-Like generator for the stubs.

Really need to play with the technology to understand and appreciate all the
good and bad points. Richard C. Allen

#: 16050 S14/Win32s Specific
    29-Oct-92  05:47:07
Sb: WIN32s
Fm: Eric M. Guli 70272,3627
To: sysop (X)

Please help!  I just received the october release of WIN32 NT at this point I
only want to load the WIN32s portion of the program
  However, I cannot load it on to either of my two computers, 1) is a Gateway
486DX/2 50 E and the other is a Gateway 486SX 25.  I know this is not a lot of
info but can anyone help.  The EISA machine loads the files or I should say
copies the files to the correct directories then gives me a fail message.  The
SX25 machine copies the files then gave me an error it could not open
WINSPOOL.DRV, so I re-copied it to the floppy and re-installed only to get a
divide by zero error or stack overflow.  My main concern is to get the EISA
machine running with WIN32s. Thanks Eric

#: 16128 S14/Win32s Specific
    29-Oct-92  15:05:55
Sb: INSTALL PROBLEM
Fm: Steve Woolley 75570,1620
To: ALL

HELP I AM TRYING TO INSTALL WIN32S. I HAVE 4M RAM PLENTRY OF DISK SPACE I
COPIED THE FILES IN MSTOOLS/WIN32S/FLOPPY ONTO A 3.5 FLOPPY, TYPED SETUP.
WINDOWS CAME UP TOLD ME IT WAS INSTALLING WIN32S AND THEN GAVE ME THE
FOLLOWING ERROR:

APPLICATION ERROR DSHELL CAUSED SEGMENT LOAD FAILURE IN MODULE _MSTEST.EXE AT
0009:0371

I BELIEVE I HAVE FOLLOWED ALL THE CORRECT PROCEDURES. HAVE ANY IDEAS?
SUGGESTIONS?

P.S. I USE STACKER, IS THIS THE PROBLEM?

#: 16175 S14/Win32s Specific
    30-Oct-92  04:44:13
Sb: Win32s - C7 link problem
Fm: Eric V. Smith 70621,3367
To: all

I have a problem running link from C7 when a Win32s app is running.  When link
starts, the entire DOS box that link is running in just vanishes. There are no
error messages.

I've actually just tried this with FreeCell, so I'm not sure if it applies to
all Win32s apps or just FreeCell.  If you can't duplicate this, let me know
and I'll try to get more info on it.

Eric.

#: 15941 S14/Win32s Specific
    27-Oct-92  21:00:15
Sb: Win32s fails
Fm: Robert Zeff 70323,1251
To: all

I get a failed message when I attempt to install Win32s per page 3 of the
WIn32s Programmer's Reference.  I get this message on two different computers.
I am running Workgroups for Windows RC2.

Any suggestions?

-Robert




There is 1 Reply.

#: 15956 S14/Win32s Specific
    28-Oct-92  07:35:32
Sb: #15941-Win32s fails
Fm: Andreas Klein 100063,1637
To: Robert Zeff 70323,1251 (X)

Please change to the final version of Windows for Workgroups. I have
successfully installed Win32s on WfW using setup (without .ini file hacking
<g>).

ciao,
   Andreas


There are 2 Replies.

#: 16016 S14/Win32s Specific
    28-Oct-92  18:31:11
Sb: #15956-Win32s fails
Fm: Robert Zeff 70323,1251
To: Andreas Klein 100063,1637

The last version I received of WFW was RC2.  How do I get a later version?

Thanks,

Robert

#: 16202 S14/Win32s Specific
    30-Oct-92  11:21:50
Sb: #15956-Win32s fails
Fm: Robert Zeff 70323,1251
To: Andreas Klein 100063,1637

> Please change to the final version of Windows for Workgroups. I have >
successfully installed Win32s on WfW using setup (without .ini file hacking

I've been informed that I won't get the final release for fout weeks.  Is
there some hacking on the .ini files that would help?

Thanks,

Robert

#: 16176 S14/Win32s Specific
    30-Oct-92  05:07:42
Sb: Changing file system
Fm: joe weissman 70473,2346
To: all

I have just uploaded the october release of win32 beta on my 386 system.  I
initially chose the NT file option.  I have a nonsupported cd rom drive that
from Philips and this drive does not run under win32 as it is not SCSI. I
would like to go back to the FAT type of file system but am not clear on how
to uninstall or modify the win32 without reloading both DOS 5.) and win win32.
Any comments would be appreciated.

There is 1 Reply.

#: 16209 S14/Win32s Specific
    30-Oct-92  13:04:08
Sb: #16176-Changing file system
Fm: Lee Hart [Microsoft] 76150,2536
To: joe weissman 70473,2346

>>>I have just uploaded the october release of win32 beta on my 386
   system.  I initially chose the NT file option.  I have a nonsupported
   cd rom drive that from Philips and this drive does not run under
   win32 as it is not SCSI. I would like to go back to the FAT type of
   file system but am not clear on how to uninstall or modify the win32
   without reloading both DOS 5.) and win win32.

This is not a Win32s question - it belongs in the WINNT forum, since it does
not even involve the SDK.  Please follow up in the filesystems section of
WINNT (Section 9).

 Lee
 Microsoft Developer Support

#: 15963 S14/Win32s Specific
    28-Oct-92  08:50:50
Sb: win32s octrel outofmem
Fm: Mark Kumler 70404,261
To: ALL

Gentel Peoples:
   I am experiencing a problem trying to run our application under win32s. The
program runs fine on the win32 platform but when I attempt to run on my 8 meg
win 3.1 system I get an out of memory error.
   I know that we are not requesting THAT much ram for our data so I must
assume that the problem lies in the loadondemand/discardable type logics for
code.  I could not find information on how to specify this type of information
to the new linker on nt.  If the information is somewhere that I have missed
(quite likely) or if there is a sample program that demonstrates this I would
be most gratefull if you could point me in the right direction - thanks. Mark
Z. Kumler Ithaca Software [e-mail] [phone] x241

PS:  The executable in question is 1852928 in size.

There is 1 Reply.

#: 16000 S14/Win32s Specific
    28-Oct-92  16:17:17
Sb: #15963-win32s octrel outofmem
Fm: Lee Hart [Microsoft] 76150,2536
To: Mark Kumler 70404,261 (X)

>>>I am experiencing a problem trying to run our application under win32s.
   The program runs fine on the win32 platform but when I attempt to run
   on my 8 meg win 3.1 system I get an out of memory error.

>>>I know that we are not requesting THAT much ram for our data so I
   must assume that the problem lies in the loadondemand/discardable
   type logics for code.  I could not find information on how to
   specify this type of information to the new linker on nt.  If
   the information is somewhere that I have missed (quite likely) or
   if there is a sample program that demonstrates this I would
   be most gratefull if you could point me in the right direction - thanks.

Several Questions:

  (1) How large is your Swap File in Windows 3.1?  Is it permanent?

  (2)Do you know how much stack space your program is using?  It's possible
you are running out of stack space.

 Lee
 Microsoft Developer Support



There is 1 Reply.

#: 16121 S14/Win32s Specific
    29-Oct-92  14:07:38
Sb: #16000-win32s octrel outofmem
Fm: Mark Kumler 70404,261
To: Lee Hart [Microsoft] 76150,2536 (X)

Lee:
  We do run the same program comiled on win 3.1 and don't have any of these
problems.
  Our swap file is the recommended maximum size and is permanent. I doubt the
stack problem since the same code will run when compiled under the 3.1
platform.

There is 1 Reply.

#: 16223 S14/Win32s Specific
    30-Oct-92  15:31:19
Sb: #16121-win32s octrel outofmem
Fm: Lee Hart [Microsoft] 76150,2536
To: Mark Kumler 70404,261

>>>We do run the same program comiled on win 3.1 and don't have any
   of these problems.

I'm not trying to pick nits, but due to the larger parameters in Win32, you
still could be running out of stack space...Fortunately there is an easy way
to check.   When you link your Win32 app, specify '-stack:128,128' on the link
command line, which will force your app to have the same stack size under
Windows NT as under Win32s.

Lee

#: 16013 S14/Win32s Specific
    28-Oct-92  17:56:20
Sb: Win32 Applications in Wi
Fm: Bill Pytlovany 70642,2122
To: All

Does anyone know of any applications which are able to run using Win32s
besides FreeCell?


I'm was the impression that if I write a Windows NT app, it will run under
Windows 3.1, if the user has Win32s librarys or if I supply them.  Am I wrong?
Do I have to create a Windows NT version and then link with libraries to give
me a Win 3.1 application?

I tried running a few of the applications included with WinNT like Solitaire,
Notepad, WinHelp32 and crashed my Win 3.1 system pretty bad.

Are these bugs?  Does this means Win32s needs alot of work or do I just have
my information all mixed up.

Thanks!
Bill Pytlovany

There are 2 Replies.

#: 16042 S14/Win32s Specific
    29-Oct-92  01:22:06
Sb: #16013-Win32 Applications in Wi
Fm: Peter Handsman[Inmark] 70550,2570
To: Bill Pytlovany 70642,2122 (X)

Bill,

I havn't done much testing of Win32s yet myself, but i've had better results
then things like your talking about.  A couple of my smaller test programs
i've ported to NT work ok with Win31 and Win32s, and i've actually taken a
liking to the WinDiff program (Which also works ok under Win32s)....

Peter Handsman Inmark Devlopment Corp.

#: 16231 S14/Win32s Specific
    30-Oct-92  16:02:17
Sb: #16013-Win32 Applications in Wi
Fm: Lee Hart [Microsoft] 76150,2536
To: Bill Pytlovany 70642,2122 (X)

>>>I'm was the impression that if I write a Windows NT app, it will run
   under Windows 3.1, if the user has Win32s librarys or if I supply them.
   Am I wrong? Do I have to create a Windows NT version and then link with
   libraries to give me a Win 3.1 application?

You are correct, as long as the Win32 application does not use any
functionality (except the Structed Exception Handling and the FP emulation
code) that does not exist in Windows 3.1.  It would really help if you try
running your apps with a 128K stack under Windows NT to eliminate the
possibility that the reduced stack size is the cause of your problems.

Also you may want to attach a terminal (or another PC) to your Windows 3.1
machine and start up wdeb386 w/ additional error logging enabled in Win32s (as
documented in the Win32s programmer's guide, pages 19-21) andsee what error
messages get spit out.

>>>Are these bugs?  Does this means Win32s needs alot of work or do I
   just have my information all mixed up.

Yes, these probably are bugs - however the more information you can give us,
the better.


 Lee
 Microsoft Developer Support



There is 1 Reply.

#: 16243 S14/Win32s Specific
    30-Oct-92  18:07:34
Sb: #16231-Win32 Applications in Wi
Fm: Bill Pytlovany 70642,2122
To: Lee Hart [Microsoft] 76150,2536 (X)

Thanks for the resonse Lee...

>>It would really help if you try running your apps with a 128K stack under
>>Windows NT to eliminate the possibility that the reduced stack size is the
>>cause of your problems.

Unfortunately, I'm unable to run Windows NT on machine at this time.  It's
incompatible because  I've choosen to test some other software at this time
which currently conflicts.  I'd wonder if this was the reason, but like I say,
FreeCell works fine.

>>Also you may want to attach a terminal (or another PC) to your Windows 3.1
>>machine and start up wdeb386 w/ additional error logging enabled in Win32s
(as >>documented in the Win32s programmer's guide, pages 19-21) andsee what
>> error messages get spit out.

Thanks for pointing out the Debugging pages in the manual  I hadn't gottent
that far yet since I haven't been able to test with my own applications yet.
I'll give it a shot and let you know if I come up with anything.

Thanks!
Bill Pytlovany

#: 16248 S14/Win32s Specific
    30-Oct-92  18:27:28
Sb: Unhandled exception
Fm: Robert Zeff 70323,1251
To: All


I am getting a "unhandeled exception" in my NT application running on Win32s.
I also get this message when running freecell.  In freecell, I get this
message when I select F3 (select new game) twice.  My applcation fails soon
after loading.  I am using the debugger, but can't figure out where the
problem is.  Any hints would be appreciated.

-Robert

#: 16001 S14/Win32s Specific
    28-Oct-92  16:18:34
Sb: Win32s: Exception ?
Fm: Robert Zeff 70323,1251
To: All

I get an "Unhandled exception detected, application terminated" message when I
run my NT application with Win32s.  What would be the next step to track down
this problem?  THe application is in lib 4 of WINNT, Spice1.zip.  The
executable is "nutmeg32.exe" in case anyone wants to try this.  It runs fine
in NT.

Thanks,

-Robert




There is 1 Reply.

#: 16208 S14/Win32s Specific
    30-Oct-92  13:04:01
Sb: #16001-Win32s: Exception ?
Fm: Lee Hart [Microsoft] 76150,2536
To: Robert Zeff 70323,1251 (X)

>>>I get an "Unhandled exception detected, application terminated"
   message when I run my NT application with Win32s.  What would
   be the next step to track down this problem?  THe application
   is in lib 4 of WINNT, Spice1.zip.  The executable is
   "nutmeg32.exe" in case anyone wants to try this.  It runs fine in NT.

Does your program run fine (no exceptions) when run under windbg and/or ntsd?
I am looking on this end to see if there are any outstanding memory
limitations with win32s right now.

 Lee
 Microsoft Developer Support



There is 1 Reply.

#: 16259 S14/Win32s Specific
    30-Oct-92  20:13:04
Sb: #16208-Win32s: Exception ?
Fm: Robert Zeff 70323,1251
To: Lee Hart [Microsoft] 76150,2536 (X)

>>Does your program run fine (no exceptions) when run under windbg and/or
ntsd?
  I am looking on this end to see if there are any outstanding memory
  limitations with win32s right now.

The program runs fine under windbg and ntsd.  When I debug under
Win32s/wdeb386, I get: KERNAL32: Unhandled exception: c0000005  IP: 809f1c6b
RaiseException in Kernal Mode

Also, I can get the same message (Different IP, of course) with freecell if I
select "select game" twice.

Another question:  Should a console program work with Win32s? Thanks, -robert




#: 15729 S15/Unicode/NLS
    23-Oct-92  21:22:33
Sb: #15724-Complete unicode font?
Fm: Paul Watson [XLsoft] 76056,1751
To: Steve Firebaugh [MS] 75430,412 (X)

We all appreciate your reply and responsiveness, Steve.

From a scenario given earlier...

The customer should be able to go to the store in any country and buy the NT
base system and W4W NT with documentation in the local language and the
Microsoft Hebrew and Arabic IME products.  These should be available or
orderable in any country.  The NT documentation describes how to install
Microsoft IME products in the local language.  The IME documentation covering
configuration and usage of the IME is in the language they support; in this
case Hebrew and Arabic.

Support for the IME is in the IME language, not the local language.  If you
want to use the IME, you must know the language.  If you want to learn Hebrew,
then buy an education package, a book, or take a class on Hebrew. Third
parties might create documentation products which describe using the Microsoft
Hebrew IME written in English, French, or any other language.

Third party IME products may or may not choose to provide documentation in any
language other than the one it supports and may or may not use the Microsoft
standard IME installation procedures.

The customer should not need to travel to Israel or sneak the Hebrew IME back
into his home country.  This is a global market.

[More]

There is 1 Reply.


#: 15730 S15/Unicode/NLS
    23-Oct-92  21:22:42
Sb: #15729-Complete unicode font?
Fm: Paul Watson [XLsoft] 76056,1751
To: Paul Watson [XLsoft] 76056,1751 (X)

[Continued]

The IME documentation will specify contact information for the point of
support for each IME product.  This should include a mailing address,
telephone, FAX number, and (*important*) and email address.  Microsoft should
establish global electronic support mechanism(s) with at least one point of
access in every country in which it does business.

If you want an instant product, have Microsoft Mail support the local support
access point(s).  This strategy will give Microsoft the ability to manage its
support requirements and give customers access worldwide.  If you don't want
customers to have access worldwide, that is another problem.

Microsoft should investigate technologies needed to deliver worldwide product
such as publishing on demand.  When the odd order for a Thai IME comes into
Microsoft GmbH, an automated system prepares the disk and prints whatever
documentation accompanies the package in Thai.  There should be no need for
the customer to delay his business three (3) weeks for a physical package to
be shipped from Thailand.

Regards...Paul



There is 1 Reply.

#: 15740 S15/Unicode/NLS
    24-Oct-92  19:27:33
Sb: #15730-Complete unicode font?
Fm: Paul Watson [XLsoft] 76056,1751
To: Paul Watson [XLsoft] 76056,1751 (X)

[Continued]

Publishing on demand also gives Microsoft quality control over the product it
delivers around the world.  The only better way would be to deliver the
product electronically direct to the target system and installed.

As I have suggested earlier, an environment as complex as NT requires a
configuration management application which will monitor installed components
and produce diagnostic reports.  These can be used to insure that the customer
has current and compatible drivers installed.

Regards...Paul

#: 15747 S15/Unicode/NLS
    25-Oct-92  07:59:43
Sb: #15411-Complete unicode font?
Fm: Neil Robinson 100016,2775
To: Steve Firebaugh [MS] 75430,412 (X)

Steve,

as has been pointed out (very eloquently) by several others, we have no
argument with MS producing localized versions of NT. I use an English language
version of Windows 3.1, live in Germany, and write software which is
user-configurable on the fly into any supported language (in essence, a
user-configurable localization). Obviously, that is overkill for most users
with something the size of NT. Still, it should be possible for me to write my
product to be user-configurable with respect to language, and have the user
able to implement that language on their version of NT without additional
fuss.

-- it should also be possible to acquire only the localization parts of the OS
as a separate part #, so that a developer can switch localization methods to
the one needed for the final user of his product. I would like to be able to
open up the International section of System Configuration and set which
localized system I am using. This makes it possible to do phone support for
several localized platforms (German Windows, French Windows, English Windows
,...) without having a separate Windows loaded for each version (say bye bye
to 8MB per version not including configuration hassles).

--the same goes for IMEs. The input methods for each localized version should
be hardware independent and should be supplied with the above named *product*
--- Localization Package For ... as well as separately. They should also be
useable from *any* version of NT.

-- it may have proved useful to have built NT on top of Unicode, but unless
the full capabilities of Unicode are implemented (I know what I am asking, but
you definitely have more man-power than I do 8-) ), we are going to be losing
a major opportunity. Even if the support doesn't come immediately, it should
be planned for.

Ciao, Neil

#: 15900 S15/Unicode/NLS
    27-Oct-92  15:23:32
Sb: #15747-Complete unicode font?
Fm: Steve Firebaugh [MS] 75430,412
To: Neil Robinson 100016,2775

Neil,

Thank you for your suggestions.  You are correct that supporting multiple
locales incurs a memory cost.  That is one of the arguments given against
equiping every version of Windows/NT with full unicode support (although it is
not the dominant one).

You wrote:

 >Even if the support doesn't come immediately, it should be planned for.

You are absolutely correct about this.  Even though my comments should
probably be taken as empty assurances, there will be greatly expanded unicode
support in future products.  For example, there is supposed to be a new text
model in place by Windows/NT "product 2" which will answer many of the complex
rendering problems (multiple code points mapping to a single, unique glyph).
I do not believe that Microsoft has made any official announcement about
"product 2," so it is not productive for me to say much about it.  Perhaps in
6 months, we will be having concrete discussions here about what it will
provide.

Steve Firebaugh

#: 15764 S15/Unicode/NLS
    26-Oct-92  04:14:08
Sb: #15724-Complete unicode font?
Fm: Tim Hyde-Smith 100023,3320
To: Steve Firebaugh [MS] 75430,412 (X)

Your last posting seems to me a good summary of what's been being said here; I
also want to thank you for your openness.  Since the European Users' Forum in
July (even though it was a cut-down version of San Francisco) and the help
I've had here on CIS in the last few months I've been getting more and more
impressed with MS' evident commitment to its ISVs.  It's very heartening.
Thanks.

- Daryl, masquerading as Tim with his knowledge and consent :->

#: 15904 S15/Unicode/NLS
    27-Oct-92  15:44:19
Sb: Uniput - input unicode c
Fm: Steve Firebaugh [MS] 75430,412
To: All

I just uploaded a sample program which provides a crude solution for inputing
unicode characters (uniput.zip).  This program does NOT represent Microsoft's
intended direction for input methods.  It is simply an interim solution that
will allow the user to input unicode text, and write it to a file.

Notice that the October beta includes a unicode enabled version of 'notepad.'
This program, named 'unipad,' will display unicode text files.  However,
unipad does not provide any way to input unicode text.  That is the need which
'uniput' was written to address. Comments or problems with this sample program
should be posted to this section.  Thanks.

Steve Firebaugh




#: 16085 S16/Tools-3rd Party
    29-Oct-92  11:06:26
Sb: Dos Apps
Fm: Don Will 72570,2733
To: sysop (X)

I have installed the October Beta and SDK.  All of my usual windows apps run
OK.  I am having problems with the Borland C++ DOS IDE, Turbo Debugger and
Tprof.  When I start them Get "OS/2" application caused a general protection
fault.  CS=0xf  IP=0x14.

I have tried running them from the PIF that NT generated and from a dos
session with the same result.  Any ideas or suggestions?
I have the BC++ IDE set for 1024k of XMS and the pif specifies up to 2000.





#: 15748 S17/Unmonitored Chat
    25-Oct-92  10:11:39
Sb: #15149-Bad Int. Support
Fm: GMS 100063,2012
To: Neil Robinson 100016,2775

Guess I can learn something here: I struggeled with the 1-800 problem for
a while now. Some companies just do not have a "normal" number. I do have
an AT&T card too. How do you dial a 1-800 number from Europe?

Gerhard


There is 1 Reply.


#: 15762 S17/Unmonitored Chat
    26-Oct-92  01:13:09
Sb: #15748-Bad Int. Support
Fm: Peter A Winskill 70323,2547
To: GMS 100063,2012

Neil,

If you have an AT&T card number, a lot of countries have a USADirect number
you can call. This allows you (among other things) to call 800 numbers and
charge them to your USA number. All numbers are at USA rates, with the 800
number charged like an ordinary area code.

With USADirect you can also call collect (i.e. if you don't have an AT&T card.
Calling collect can be a lot cheaper than calling and paying the local country
rates.

Some examples of USADirect numbers from these countries are: UK -
0800-89-0011; Spain - 900-99-00-11; Taiwan - 0080-10288-0; Germany -
0130-0010; Japan - 0039-111.

Let me know if you need numbers for any other countries. Either that or take
an international flight and rip a USADirect card outta the flight magazine
(should be expense accountable right <G>!).

Pete

#: 15915 S17/Unmonitored Chat
    27-Oct-92  17:44:45
Sb: Bad Int. Support
Fm: Ulrich Paul 100022,3315
To: Sigurdur St. Hjalmarsson 100063,1446

I am located in Germany and I have expierienced the same problem: For
Americans we all are "Eurasians" and very far away. Propably they can't
believe that intelligent life is out there. [A/exit

#: 15953 S17/Unmonitored Chat
    28-Oct-92  07:24:05
Sb: Friendly Comparisons
Fm: Paul Pignatelli 76367,2721
To: Andy Champ 100064,2267 (X)

Hi, Andy,

Just checked back on the forum today, sorry for the delay.  (Today is Bill
Gates' birthday, so I posted a HAPPY BIRTHDAY  message to him in the 1st
section here.)  You restored my faith in ICL!    I look foreward to receiving
the info that was sent.  Thanks for your help,     Paolo

#: 16005 S17/Unmonitored Chat
    28-Oct-92  16:25:00
Sb: Spice32 for October
Fm: Robert Zeff 70323,1251
To: All

I have uploaded Spice32 / Nutmeg32 for the October release to Lib 1. -Robert

#: 16068 S17/Unmonitored Chat
    29-Oct-92  08:47:53
Sb: ISV Dev'pment Lab
Fm: Dag Baardsen [PS Norway] 100010,2257
To: sysop (X)

Hi any of you ever been to MS ISV Development Lab and would like to share some
experiences on that one?  A team from my company will be leaving for the lab
late November, so if you have some tips, let me have them!

Dag