From: SMTP%"ntdev@atria.com" 17-DEC-1997 17:05:50.10 To: ntdev-digest@atria.com CC: Subj: [ntdev] ntdev-digest V1 #396 Return-Path: owner-ntdev@atria.com Received: by arisia.gce.com (UCX V4.1-12C, OpenVMS V7.1 VAX); Wed, 17 Dec 1997 17:03:24 -0500 Received: from gw.atria.com (gw.atria.com [192.88.237.2]) by mercury.mv.net (8.8.8/mem-971025) with SMTP id GAA08113 for ; Wed, 17 Dec 1997 06:42:25 -0500 (EST) Received: by gw.atria.com id Wed, 17 Dec 1997 00:35:49 -0500 Received: from milan.doe.ernet.in by gw.atria.com id Wed, 17 Dec 1997 00:35:37 -0500 Received: from sac.ernet.in ([202.141.100.40]) by milan.doe.ernet.in (4.1/SMI-4.1) id AA17908; Wed, 17 Dec 97 10:56:40+050 Received: from milan.doe.ernet.in by sac.ernet.in (4.1/SMI-4.1) id AA15247; Wed, 17 Dec 97 10:45:34 HKT Received: from gw.atria.com by milan.doe.ernet.in (4.1/SMI-4.1) id AA09928; Wed, 10 Dec 97 06:57:14+050 Received: by gw.atria.com id Tue, 9 Dec 1997 19:30:22 -0500 Date: Tue, 9 Dec 1997 19:30:22 -0500 Message-Id: <199712100030.TAA00761@gw.atria.com> From: owner-ntdev-digest@atria.com (ntdev-digest) To: ntdev-digest@atria.com Subject: [ntdev] ntdev-digest V1 #396 Reply-To: ntdev@atria.com Sender: owner-ntdev@atria.com Precedence: bulk X-Majordomo-Taboo: ntdev ntdev-digest Tuesday, December 9 1997 Volume 01 : Number 396 ---------------------------------------------------------------------- Date: Tue, 09 Dec 1997 11:13:13 +0200 From: Eran Dvir Subject: [ntdev] LSA Documentation This is a multi-part message in MIME format. - --------------B1C8AA200846728F7D105623 Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Can anyone tell me where I can find information about the LSA? Thanx - ---------------------- Eran Dvir eran@netect.com Netect Ltd. - --------------B1C8AA200846728F7D105623 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Eran Dvir Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Eran Dvir n: Dvir;Eran org: Netect Ltd. adr: 13 Gush Etzion St.;;;Givat Shmuel;;;Israel email;internet: eran@netect.com tel;work: +972 - 3 - 5320544 Ext.25 tel;fax: +972 - 3 - 5320545 x-mozilla-cpt: ;0 x-mozilla-html: FALSE end: vcard - --------------B1C8AA200846728F7D105623-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] ------------------------------ Date: Tue, 9 Dec 1997 02:35:56 -0800 From: "T.D. Brown" Subject: Re: [ntdev] Record size <--- thank you! I want to thank every one who replied. Your answers were helpful and very educational. Thank you, Tom - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] ------------------------------ Date: Tue, 9 Dec 1997 11:17:05 +0100 From: Ewold Kok Subject: [ntdev] Difference between ISA and PCI Hello Can someone tell me what the difference are between sending data to a PCI card and sending data to a ISA card. Can someone also tell me what the difference is between port IO and memory IO - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] ------------------------------ Date: Tue, 09 Dec 1997 12:09:07 +0100 From: Abderrahim Berriche Subject: Re: [ntdev] DLL collision problem or red herring? Paul Ashton wrote: > > At 10:33 08/12/97 +0100, Abderrahim Berriche wrote: > >Paul Ashton wrote: > >> The program always works the first time and then works arbitrarily > >> thereafter depending on which machine it is run on, how much memory > >> it has and how much paging space it has. The less memory a machine > >> has the more likely it is to work the second and later attempt. > >> If I write a little C program to use up and write to each page of > >> 80megs of memory, say, then the program will always work after I > >> run the memory allocation program. > > >>... > > >> Although I would expect there to be a few collisions, the fact > >> that it seems to depend on something cached by the OS, i.e. a > >> DLL leads me to believe that some program is reliant on a > >> fixed address and the collisions are affecting it. Is this > >> a valid conclusion? Anybody any idea what might be going on? > > > This may happen when a DLL declares a section as shared. In this case > >the loader will try to load this section at the same address in all > >the processes that will load the dll. However it a fixup is needed > >for the shared section it is just replaced by allocating a new > >physical page for that section and modifying the virtual memory > >mapping for the process when the fixup has occured. > > The problem is that You will not get any warning for this case. This > >will end up in that the processes will use different copies of the > >declared shared section. I let you imagine what this will ends up in. > > Another point is that if you have a pointer to somepart in this > >section it will not be fixed I think. > > > >For further details see Q109619 and Q125677 in the knowledge base. > > Thanks for the pointers. Could you or someone else just clarify > what happens to a DLL after all processes using it terminate? This depends on how the processes will terminate. When the process is terminated using ExitProcess the dllEntryPoint function is called with the DLL_PROCESS_DETACH argument which let the dll make some cleanups before exiting. However if the process is terminated with TerminateProcess the dll will not be notified and the the dll could not perform any cleanup. The dll code will remain in memory as long as there is still a process using this dll. > How come it is possible to get collisions with the DLL even if I rename > it so that it is not loadable any more? Strange! I think that your application was able to find a dll with the same name in the Dlls search path. > Does your shared section > hypothesis agree with the behaviour shown after I cause all > swap to be used and thus kick the DLL out of cache? > I don't think so. abder. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] ------------------------------ Date: Tue, 09 Dec 1997 11:12:35 +0000 From: Paul Ashton Subject: Re: [ntdev] DLL collision problem or red herring? At 12:09 09/12/97 +0100, Abderrahim Berriche wrote: >> >Paul Ashton wrote: >> Thanks for the pointers. Could you or someone else just clarify >> what happens to a DLL after all processes using it terminate? >This depends on how the processes will terminate. When the >process is terminated using ExitProcess the dllEntryPoint function >is called with the DLL_PROCESS_DETACH argument which let the dll >make some cleanups before exiting. However if the process is >terminated with TerminateProcess the dll will not be notified and >the the dll could not perform any cleanup. The dll code will remain >in memory as long as there is still a process using this dll. Herein lies the problem. The process has definitely gone. There appears to be nothing that a DLL could be attached to. But it *still* appears to be cached. >> How come it is possible to get collisions with the DLL even if I rename >> it so that it is not loadable any more? >Strange! > I think that your application was able to find a dll with the >same name in the Dlls search path. Definitley not. There were 2 and I renamed them both and searched the whole disk for others. >> Does your shared section >> hypothesis agree with the behaviour shown after I cause all >> swap to be used and thus kick the DLL out of cache? > I don't think so. So shared sections can't outlive processes? Paul - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] ------------------------------ Date: Tue, 9 Dec 1997 07:46:04 -0500 From: Michael Shiels Subject: [ntdev] Enhanced Meta Files and various printers If you capture an Enhanced Meta File (not too hard too do with a print = processor) isn't it going to still be "printer specific"? Or does the = Spooler when calling gdiPlaySpoolStream end up emulating things the = printer doesn't understand? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] ------------------------------ Date: Tue, 9 Dec 1997 08:44:09 -0500 From: "Bruce D. McLeod" Subject: [ntdev] Partition numbers Greetings... I am playing some games with disk redirection at a device level. I've been mostly successful, except that I noticed that calls to IoReadPartition do not correctly fill in the PartitionNumber field of the partition entries. They come out as 0x23456789, which I assume is uninitialized memory. I do not see anything in the on-disk partition tables about partition numbers, so I assume they are calculated somehow. Does anyone know how this calculation is done, or how I can spoof it? Thanks. Bruce McLeod GigaNet - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] ------------------------------ Date: Tue, 9 Dec 1997 11:26:39 -0400 From: "Jeff Bonsteel" Subject: [ntdev] NTICE Curious item in LOG Anybody know what this means? It was in the softice log in WinNt. .. NTTerminateProcess found at index 00BB. Delta=00000000 NTRaiseHardError found at index 0085. Delta=00000000 NTICE: i8042prt patch1 at F8F61304 NTICE: i8042prt patch2 at F8F60C28 NTICE: i8042prt patch3 at F8F60C47 NTICE: i8042prt succesfully patched. .. I'm having trouble with som process terminates and wonder if this is a factor??? Jeff - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] ------------------------------ Date: Tue, 9 Dec 1997 10:44:14 -0600 (CST) From: Dave McMullen Subject: [ntdev] NT Dev Driver Resource Book Does anyone know how I can get a copy of: The Windows NT Device Driver Resource Book Any comments reguarding the contents? Will it truely aid the want-a-be driver writer? How does it compare to the Baker book? - -- Thanx, davem. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] ------------------------------ Date: Tue, 9 Dec 1997 12:18:34 -0500 From: "Sanford Hayes" Subject: [ntdev] Big / Little Endian Conversions on PLX9050 Hi I am Having No luck at all getting a PLX9050 PCI interface chip to do the documented Big / Little Endian conversions from the PC to the local memory on the PCI card. Does anyone here have any expierence with this chip and these conversions ? TIA Sanford - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] ------------------------------ Date: Tue, 9 Dec 1997 19:18:50 +0200 From: "VideoCad Ltd." Subject: [ntdev] WinDBG for VC5.0 Greetings... We are lost trying to make the Windbg working with VC5.0 symbols... We get PDB checksum error although we are using the Platform SDK downloaded from Microsoft site, and forfilled all instructions (USE_PDB, PDB:...) The Platform SDK did not contain any new WinDBG.EXE. Can someone indicate where we can get JUST the updated WindDBG.EXE itself? Many Thanks in advanced, Menachem Zibziner VP R&D ___________________________________ VideoCad Ltd. Motion Digital Video Products 57 Hamelacha St., Holon, 58885, ISRAEL Tel: +972-3-5584448, Fax: +972-3-5584449 E-Mail: videocad@netvision.net.il Web site: http://www.vdomain.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] ------------------------------ Date: Tue, 9 Dec 1997 10:39:38 -0700 From: CBudd@inter-tel.com Subject: Re: [ntdev] NT Dev Driver Resource Book I found it on the July 1997 MSDN Library and the October 1997 MSDN Library; search for the string (with quotes) "What the Heck is Windows NT". It is what it says it is, and not what you think it is. The abstract says it all: "this article presents an overview of Microsoft Windows NT device driver programming and a comprehensive reading list." Personally, I think the overview of the programming aspect is lacking; however, the reading list is quite comprehensive and complete, although somewhat outdated now. For a beginning how-to book, I have heard Baker's book is quite good, but it has a couple mistakes. Below I'll repost my list of driver references. (Sorry for those that have seen it before many times.) You might also try some or all of the following device driver (almost week-long) classes: o David Solomon Expert Seminars, http://www.solsem.com/ , 800-492-4898. I took their four-day class (from NT internals to advanced driver topics) and can recommend it. o Open Systems Resources, http://www.osr.com/ , 603-595-6500. I have heard many good things about their classes. o Hands On Technology Transfer (HOTT), 800-413-0939. Took their C++ class; it was good, know nothing about their NT driver class. o Art Baker offers an NT driver course through Cydonix (no contact information available). Some good references include: o KMS -- Jamie Hanrahan: http://www.cmkrnl.com/ contains many links and an NT driver FAQ with many more resources (including video order information) o Cherry Hill Driver Development: http://www.albany.net/~danorton/ddk/ contains many links and a Windows (3.1, 95, NT) driver FAQ o Open Systems Resources, http://www.osr.com/ , 603-595-6500. publishes a good bimonthly (free?) newsletter, "The NT Insider" o NT Internals: http://www.ntinternals.com/ntinternals.htm o Intec DDK: http://www.intec.es/ddk/ o GNU Win32: http://www.cygnus.com/misc/gnu-win32/ o WinNT Dev Tips: http://www.localweb.com/jkc/devtips/ o NTDEV Archives: ftp://ftp.atria.com/archives/ntdev/ You might also try using a driver wizard or prepacked drivers if your interface is simple: o "Driver::Works", from Vireo Software, 508-264-9200 http://www.vireo.com; free demo o "WinRT", from BlueWater Systems, 206-771-3610, http://www.bluewatersystems.com/ o "DeviceX", from WinStar Technologies, 415-647-2815, http://www.wintech.com/ In addition, o DDK (and possibly SDK) from MS, of course. o Helen Custer's "Inside Windows NT", MS Press, ISBN 1-55615-481-X. New version from David Solomon coming soon. o Jamie Hanrahan also has an NT driver book due soon. o Art Baker's The Windows NT Device Driver Book: A guide for programmers Prentice Hall, ISBN 0131844741 Good luck, Chris To: ntdev@atria.com cc: (bcc: Chris Budd/Inter-Tel) Subject: [ntdev] NT Dev Driver Resource Book Does anyone know how I can get a copy of: The Windows NT Device Driver Resource Book Any comments reguarding the contents? Will it truely aid the want-a-be driver writer? How does it compare to the Baker book? - -- Thanx, davem. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] ------------------------------ Date: Tue, 9 Dec 1997 10:55:23 -0800 From: "Jamey Kirby" Subject: Re: [ntdev] huge files FAT and NTFS do not support sparse file allocation. This is what is causing the delay. The system must physicaly allocate the space from the disk. In NTFS 5.0, sparse allocation issupported and your create request should respond instantly. Jamey Kirby Senior Partner Magnuson, Kirby & Associates, LLC. jkirby@cts.com http://www.mkallc.com - -----Original Message----- From: Alexander E. Sobol To: ntdev@atria.com Date: Monday, December 08, 1997 11:28 PM Subject: [ntdev] huge files >Hello ! >I need to create a really big file (2GB). >I do not mind if there is rubbish in the file. > >I tried to use CreateFile - SetFilePointer - SetEndOfFile - CloseFile >standard calling sequence. > >It did work, but I couldn't run any programs for few minutes. >Program stalls after CloseFile is issued. > >What is it doing ? > >is it possible to grow a file without this pain ? > >Any hints will be appreciated. > >TYA, >Sasha > > > > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >[ To unsubscribe, send email to ntdev-request@atria.com with body >UNSUBSCRIBE (the subject is ignored). ] > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] ------------------------------ Date: Tue, 09 Dec 1997 12:12:46 -0800 From: Richard Hartman Subject: [ntdev] RE: Architecture: K6 vs. PMMX At 02:06 AM 12/9/97 -0800, you wrote: >Did you ever get a decent answer on this one? Not really. I've since built two K6-based NT machines and am so happy with their performance that K6's are all I specify now. While I've not done direct A-B comparisons, I must say that compiles are much faster than on the Intel CPU's. PerfMon shows the CPU is able to run at 100% more of the time, which means the CPU isn't waiting on slower resources (such as L2 cache) as often. My admittedly weak interpretation of that is that the 4X larger L1 cache is making the difference - the CPU is running at full speed more of the time because it doesn't have to go off-chip as often. Two more tidbits, gleaned from research papers into CPU architecture: 1) There's a declining return as core speed exceeds bus speed by more than 2X. 2) But the greater the core/bus ratio, the more impact the cache has on performance. This is true in every parameter: The closer the cache the better (L1 has more impact than L2), the larger the cache the better, the faster the cache the better, etc. These two details, taken together, support the argument that the K6's larger L1 cache would make a difference - and that the performance improvement would increase as the core/bus ratio gets larger. This is starting to show up in real world tests of motherboards such as the Shuttle HOT-603 and VIA PA-2007, which have 2X the normal L2 cache... when those boards are run with higher core speed K6 CPU's, their performance gain is "more than the clock speed". Another way of looking at that is to say that higher core CPU clock speeds are wasted if you don't back them up with appropriate L1 and L2 caches. If you think about it, ALL storage is really the same - it just gets slower and larger as you get farther from the CPU. L1 is smallest and fastest, L2 is larger and slower, main memory is even larger and even slower, disk is even larger and even slower, network is even larger and even slower. It really IS important to architect the entire system, front to back, for optimal performance. Hope this helps. RLH - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] ------------------------------ Date: Tue, 9 Dec 1997 12:07:26 -0800 From: "Jamey Kirby" Subject: Re: [ntdev] Partition numbers Bruce, I have been playing with the same thing for a solid week. I pulled 38 hours straight (slept last night) trying to understand how and what the DRIVE_LAYOUT_INFORMATION structre is and how it interfaced with WINDISK.EXE (aka: Disk Administrator). Apparently, the IoReadPartitionTable() and IoWritePartitionTable() were written before support for dynamic partitioning. These routines reside in the HAL. The DRIVE_LAYOUT_INFORMATION structure has been modified to handle dynamic partitioning, but the HAL routines do not initialize certian fields. This is, in part, because there is no partition number field that resides on the physical disk. This field is initialized via the disk device drivers during partition initilization and IOCTL_DISK_SET_DRIVE_LAYOUT. It is used by WINDISK.EXE to keep track of the partition ordinal as defined by the system device drivers. WINDISK will start confusing and losing drive letters if this field is not maintained properly by the device driver managing the partition device objects. If you have a disk driver sitting below you, you will get the correct information by issuing the IOCTL to that driver rather than using IoReadParttionTable(). Otherwise, your driver will require some extra work to maintain the partition number. It is obvious that dynamic partitioning was hacked into NT at the last moment. The device drivers do a poor job of isolating the code to clarify how all of this works. I am not bashing MS on this, having dynamic partition support in any form is better than not having it at all or having to wait for it.. I figured it out by spending many hours tracing drivers in SoftIce before I truly understood the semantics (I am a slow learner). 5.0 should solve many of these problems. Regards, Jamey Kirby Senior Partner Magnuson, Kirby & Associates, LLC. jkirby@cts.com http://www.mkallc.com - -----Original Message----- From: Bruce D. McLeod To: 'ntdev@atria.com' Date: Tuesday, December 09, 1997 11:32 AM Subject: [ntdev] Partition numbers >Greetings... > I am playing some games with disk redirection at a device level. I've been mostly >successful, except that I noticed that calls to IoReadPartition do not correctly fill >in the PartitionNumber field of the partition entries. They come out as 0x23456789, which >I assume is uninitialized memory. I do not see anything in the on-disk partition >tables about partition numbers, so I assume they are calculated somehow. Does >anyone know how this calculation is done, or how I can spoof it? Thanks. > >Bruce McLeod >GigaNet > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >[ To unsubscribe, send email to ntdev-request@atria.com with body >UNSUBSCRIBE (the subject is ignored). ] > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] ------------------------------ Date: Tue, 09 Dec 1997 14:52:21 -0600 From: Mehrshad Setayesh Subject: [ntdev] Accessing the tool help functions in NT Hi there to everyone: I need to access the tool help functions in a Windows NT application to perform some process manipulation. I found out the right function prototypes in . They are also imported by "th32.lib" which is an import library for "kernel32.dll". I performed a run-time dynamic linking to "KERNEL32.lib" to use the exported functions. The system loaded the library all right and returned a handle but the GetProcAddress returned NULL for functions specified in . I then decided to do a load-time dynamic linking between my application and the "th32.lib" import library. An error was issued by the system at load time saying that all of procedures (from ) entry points could not be located in "kernel32.dll". I was surprised at this message and tried to do some digging. I found out that "th32.lib" imports all prototypes of all right, and points to "kernel32.dll" as the actual code location. However "kernel32.dll", indeed, does not have an entry point for any of these functions. By digging further into the online help (using the Query) I discovered the below text in "Accessing the Tool Help Functions" section: // File scope globals. These pointers are declared because of the need // to dynamically link to the functions. They are exported only by // the Windows 95 kernel. Explicitly linking to them will make this // application unloadable in Microsoft(R) Windows NT(TM) and will // produce an ugly system dialog box. static CREATESNAPSHOT pCreateToolhelp32Snapshot = NULL; static MODULEWALK pModule32First = NULL; static MODULEWALK pModule32Next = NULL; static PROCESSWALK pProcess32First = NULL; static PROCESSWALK pProcess32Next = NULL; static THREADWALK pThread32First = NULL; static THREADWALK pThread32Next = NULL; ...... The points I wonder about are: 1. If the code for tool help functions are only in "KERNEL32.dll" of Windows 95 and not in Windows NT why the "th32.lib" and are included in the MSDEV4.0 for NT systems? 2. Could it be that these files are included because the code is placed in another dll somewhere else and if so where? 3. Has anybody been successful to use tool help functions in an NT environment? If any one out there can shed some lights on these points the effort will be greatly appreciated. Thank you for your time. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] ------------------------------ Date: Tue, 09 Dec 1997 13:34:59 -0800 From: Peter Craft Subject: Re: [ntdev] RE: Architecture: K6 vs. PMMX Richard Hartman wrote: > > At 02:06 AM 12/9/97 -0800, you wrote: > >Did you ever get a decent answer on this one? > > Not really. I've since built two K6-based NT machines and am so happy with > their performance that K6's are all I specify now. While I've not done > direct A-B comparisons, I must say that compiles are much faster than on the > Intel CPU's. PerfMon shows the CPU is able to run at 100% more of the time, > which means the CPU isn't waiting on slower resources (such as L2 cache) as > often. Richard, What is PerfMon, and how is it implemented? All of the performance tools that I've ever encountered are not able to determine that the CPU is stuck waiting for a fetch from L2 cache, or memory. In other words, the CPU would be marked busy while it fetches the needed instructions and or data. About the only way that I can imagine a performance tool would accomplish what you suggest, is by utilitizing some of the performance tuning features of the P6 and above.. even then I'm not sure how it could be done. If I'm wrong, please clarify.. Pete - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] ------------------------------ Date: Tue, 09 Dec 1997 13:37:24 -0800 From: Richard Hartman Subject: Re: [ntdev] RE: Architecture: K6 vs. PMMX >> I've since built two K6-based NT machines and am so happy with >> their performance that K6's are all I specify now. While I've not done >> direct A-B comparisons, I must say that compiles are much faster than on the >> Intel CPU's. PerfMon shows the CPU is able to run at 100% more of the time, >> which means the CPU isn't waiting on slower resources (such as L2 cache) as >> often. > >What is PerfMon, and how is it implemented? Performance Monitor, a standard tool which ships with NT. >All of the performance >tools that I've ever encountered are not able to determine that >the CPU is stuck waiting for a fetch from L2 cache, or memory. All I said was that PerfMon showed the CPU at 100% more of the time. The interpretation of that detail into cache behavior was just that - an interpretation by me. I don't know if PerfMon can discern cache fetches, but I doubt it... I don't think NT gives that level of visibility to any program running under it. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] ------------------------------ Date: Tue, 09 Dec 1997 13:49:52 -0800 From: Peter Craft Subject: Re: [ntdev] RE: Architecture: K6 vs. PMMX Richard Hartman wrote: > > >> I've since built two K6-based NT machines and am so happy with > >> their performance that K6's are all I specify now. While I've not done > >> direct A-B comparisons, I must say that compiles are much faster than on the > >> Intel CPU's. PerfMon shows the CPU is able to run at 100% more of the time, > >> which means the CPU isn't waiting on slower resources (such as L2 cache) as > >> often. > > > >What is PerfMon, and how is it implemented? > > Performance Monitor, a standard tool which ships with NT. > > >All of the performance > >tools that I've ever encountered are not able to determine that > >the CPU is stuck waiting for a fetch from L2 cache, or memory. > > All I said was that PerfMon showed the CPU at 100% more of the time. The > interpretation of that detail into cache behavior was just that - an > interpretation by me. I don't know if PerfMon can discern cache fetches, but > I doubt it... I don't think NT gives that level of visibility to any program > running under it. The reason I ask is because I'm wondering if your performance gain can be attributed to the CPU. If the K6 and P6 (I assume) are running the same job, and the K6 is A) faster and B) running at a higher CPU load, that indicates that it is stalled less often (as you point out). Since perfmon can't determine that the CPU is stalled for memory or cache, it must be stalled for disk, which would imply that your perhaps your disk I/O on your K6 machine is faster than on your Intel machine.. Just a thought. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] ------------------------------ Date: Tue, 9 Dec 1997 14:13:28 -0800 From: Lee Hart Subject: RE: [ntdev] Accessing the tool help functions in NT ToolHelp is supported on Win95 and NT5 (and later). MSDev (like our SDKs) supports development for both Windows NT and Windows 95 so it includes some libraries, headers, etc. that are only available on one platform or another. Thanks. Lee Not a Microsoft spokesperson -----Original Message----- From: Mehrshad Setayesh [SMTP:mehrshad@canmax.com] Sent: Tuesday, December 09, 1997 12:52 PM To: ntdev@atria.com Subject: [ntdev] Accessing the tool help functions in NT Hi there to everyone: I need to access the tool help functions in a Windows NT application to perform some process manipulation. I found out the right function prototypes in . They are also imported by "th32.lib" which is an import library for "kernel32.dll". I performed a run-time dynamic linking to "KERNEL32.lib" to use the exported functions. The system loaded the library all right and returned a handle but the GetProcAddress returned NULL for functions specified in . I then decided to do a load-time dynamic linking between my application and the "th32.lib" import library. An error was issued by the system at load time saying that all of procedures (from ) entry points could not be located in "kernel32.dll". I was surprised at this message and tried to do some digging. I found out that "th32.lib" imports all prototypes of all right, and points to "kernel32.dll" as the actual code location. However "kernel32.dll", indeed, does not have an entry point for any of these functions. By digging further into the online help (using the Query) I discovered the below text in "Accessing the Tool Help Functions" section: // File scope globals. These pointers are declared because of the need // to dynamically link to the functions. They are exported only by // the Windows 95 kernel. Explicitly linking to them will make this // application unloadable in Microsoft(R) Windows NT(TM) and will // produce an ugly system dialog box. static CREATESNAPSHOT pCreateToolhelp32Snapshot = NULL; static MODULEWALK pModule32First = NULL; static MODULEWALK pModule32Next = NULL; static PROCESSWALK pProcess32First = NULL; static PROCESSWALK pProcess32Next = NULL; static THREADWALK pThread32First = NULL; static THREADWALK pThread32Next = NULL; ...... The points I wonder about are: 1. If the code for tool help functions are only in "KERNEL32.dll" of Windows 95 and not in Windows NT why the "th32.lib" and are included in the MSDEV4.0 for NT systems? 2. Could it be that these files are included because the code is placed in another dll somewhere else and if so where? 3. Has anybody been successful to use tool help functions in an NT environment? If any one out there can shed some lights on these points the effort will be greatly appreciated. Thank you for your time. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] ------------------------------ Date: Tue, 09 Dec 1997 15:18:20 -0800 From: Jan Bottorff Subject: Re: [ntdev] RE: Architecture: K6 vs. PMMX At 12:12 PM 12/9/97 -0800, Richard Hartman wrote: >Not really. I've since built two K6-based NT machines and am so happy with >their performance that K6's are all I specify now. While I've not done >direct A-B comparisons, I must say that compiles are much faster than on the >Intel CPU's. PerfMon shows the CPU is able to run at 100% more of the time, >which means the CPU isn't waiting on slower resources (such as L2 cache) as >often. My admittedly weak interpretation of that is that the 4X larger L1 >cache is making the difference - the CPU is running at full speed more of >the time because it doesn't have to go off-chip as often. I hate to be the bearer of bad news, but perfmon showing more time spend at 100% cpu utilization is an indication of LOWER cpu performance, everything else being equal. Perfmon will not break out time spend waiting for data from cache vs. time spent doing calculation, they are ALL cpu time. Installing the processor performance counter extensions from the NT resource kit can show this info on appropriate processors (PentiumPro/Pentium II). If you look at it this way, perfmon shows a percentage of time in each sample period where the cpu was not waiting for I/O or idling. If you have x units of work to do, and one cpu spent 50% of a sample period and the other spend 75% of a sample period doing the same work, the LOWER number represents a faster processor. Just looking at the cpu utilization may not me that meaningful anyway for problems with a mixture of I/O and processing (like most problems). Certain CPU's may also have performance advantages over other CPU's for specific problems, for example faster floating point, or faster memory copy performance (very important for problems that do large amounts of data I/O calls that actually hit the file system cache). Measuring the amount of time your specific problem takes, like compiling, certainly is a meaningful way to measure useful performance. You said the K-6 was faster at compiling, compared to which processor? under identical conditions? I agree the K-6 is probably a faster cpu than other Socket 7 CPU's, but don't believe it's faster than PentiumPro's or Pentium II's. It's rather hard to compare (impossible) under identical conditions, as these chips use different chipsets. - - Jan ___________________________________________________________________ Paradigm Matrix, San Ramon California "Development services for Win32 platforms" Internet: Jan Bottorff janb@pmatrix.com WWW http://www.pmatrix.com Phone: voice (510) 803-9318 fax (510) 803-9397 PGP: public key fingerprint 52 CB FF 60 91 25 F9 44 6F 87 23 C9 AB 5D 05 F6 ___________________________________________________________________ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] ------------------------------ Date: Tue, 09 Dec 1997 15:56:04 -0800 From: Richard Hartman Subject: Re: [ntdev] RE: Architecture: K6 vs. PMMX At 03:18 PM 12/9/97 -0800, you wrote: >At 12:12 PM 12/9/97 -0800, Richard Hartman wrote: >>Not really. I've since built two K6-based NT machines and am so happy with >>their performance that K6's are all I specify now. While I've not done >>direct A-B comparisons, I must say that compiles are much faster than on the >>Intel CPU's. PerfMon shows the CPU is able to run at 100% more of the time, >>which means the CPU isn't waiting on slower resources (such as L2 cache) as >>often. >I hate to be the bearer of bad news, but perfmon showing more time spend at >100% cpu utilization is an indication of LOWER cpu performance.... I don't think this is universally true. Granted, if a poorly written program is sitting in an idle loop polling for work to do, the CPU will be 100% consumed and that's an indication of poor performance. But if the CPU is waiting for data from an external resource (the most obvious example being a disk), the CPU will read lower utilization but the work will proceed more slowly. So simply saying that 100% CPU is an indication of poor performance is NOT universally true... the question is what amount of time is the CPU able to do useful work, and THAT is a figure you'd like to have at or near 100%. In my tests under VC4.2 doing compiles of combined C/C++/Assembly, the K6 spends more of its time at 100% and the compiles are faster than the exact same task on a Pentium. There is a burst of 100% in the beginning, followed by some disk activity during which CPU utilization drops, then disk I/O all but ceases and the CPU goes back to 100% for a while as VC steps through the source files. I believe the initial burst is while VC is compiling the header files; the disk I/O is when VC is writing the resulting .PCH file to disk (during which the CPU is waiting on the disk and thus at a lower utilization level); and then the source files can be compiled almost entirely in memory with minimal disk output to write the .OBJ files. In summary, the ideal is to have your CPU busy doing useful work 100% of the time, never waiting on external resources. This condition will result in a PerfMon reading of 100%. I agree there are other conditions which can _also_ yield a reading of 100% and which are _not_ optimum, but a reading of 100% is not automatically an indication of inefficiency. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] ------------------------------ Date: Tue, 9 Dec 1997 16:28:14 -0800 From: "Chen, Mike (Anaheim)" Subject: [ntdev] Process ID of a service Hi. I have a service which already setup in NT. After I call StartService() to start it, how can I get the process id for it ? Thanks in advance. Mike. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] ------------------------------ End of ntdev-digest V1 #396 *************************** - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-digest-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ]