Prev: What is watchdog!WdUpdateRecoveryState: Recovery enabled.?
Next: Intermediate driver (IM) installation using DPFx question
From: Maxim S. Shatskih on 17 Jan 2006 22:25 > Using external makefiles (other than makefile.def) is not supported under > the DDK. Why? NTTARGETFILES= and then MAKEFILE.INC -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation maxim(a)storagecraft.com http://www.storagecraft.com
From: Maxim S. Shatskih on 17 Jan 2006 22:34 > This is highly unusual, why on earth do we get the sdk files in the ddk > if we cannot use nmake? BUILD is wrapper around NMAKE. It gives you, for instance, the automatic dependency scan (NMAKE IIRC cannot. With GCC, you can ask the compiler to "list all #include dependencies to stdout", but the MS's compiler seems to not support it. I dunno how "checking dependencies" feature in MSVC IDE is done). If you are not satisfied with the power of BUILD (read the MAKEFILE.DEF to see how the standard macros work) - then declare the NTTARGETFILES macro in your SOURCES and this will force inclusion of MAKEFILE.INC, which is the usual NMAKE makefile (but with BUILD macros like TARGET still available there). You can also declare NTTARGETFILES=Target in SOURCES, and then use: Target: command arg1 arg2 in MAKEFILE.INC, this is the way to include the custom post-build steps (I run REBASE this way). You can also use NTTARGETFILE0=Target - this is the pre-build step (often used to compile the event log message files). The .RC files are compiled automatically, just list them among the SOURCES. If you need Unicode stringtables - just #include them to ANSI RC file, but you will need to manually add the dependency to MAKEFILE.INC as: myproj.rc: myproj.msg and use NTTARGETFILE0= with empty body. The MSG file is the Unicode stringtable, #included to ANSI .RC file. The .DEF file must just have the same name as target. -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation maxim(a)storagecraft.com http://www.storagecraft.com
From: Maxim S. Shatskih on 17 Jan 2006 22:36 All NT-only software must be Unicode-only. Otherwise, a) you force the OS to convert the strings each time b) you're dependent on user's Control Panel setup c) localizing the app to Japanese and other Far East is a nightmare. DBCS are one of the most nasty inventions in computing. -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation maxim(a)storagecraft.com http://www.storagecraft.com <zzz> wrote in message news:uLevXK8GGHA.3056(a)TK2MSFTNGP09.phx.gbl... > Yes, it works, thank you. I believe the unicode is unnecessary, > unless one wants to work with L"" strings... > thanks. > >
From: Ivan Brugiolo [MSFT] on 18 Jan 2006 02:18 I know, and, I did suggest the in a follow-up posting. My point was that running a makefile that is not "dependent" from the sources file is a way to ask for trouble. It's better to relay on standard ways of doing things and divert from the beaten path only when needed, than trying to list all the possible variations of environment variable and command line options of every tool that could make things to work or not to work. -- This posting is provided "AS IS" with no warranties, and confers no rights. Use of any included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm "Maxim S. Shatskih" <maxim(a)storagecraft.com> wrote in message news:u7P3t59GGHA.3984(a)TK2MSFTNGP14.phx.gbl... >> Using external makefiles (other than makefile.def) is not supported under >> the DDK. > > Why? NTTARGETFILES= and then MAKEFILE.INC > > -- > Maxim Shatskih, Windows DDK MVP > StorageCraft Corporation > maxim(a)storagecraft.com > http://www.storagecraft.com >
From: Anonymous on 18 Jan 2006 06:24
Win32 was traditionally non unicode COM _is_ unicode hence atl programmers need to define unicode, but not win32 programmers. I always work with non unicode, and there are no problems, the simplicity of it is so refreshing, ASCII forever, yeah!! "Maxim S. Shatskih" <maxim(a)storagecraft.com> wrote in message news:%236YMv$9GGHA.1088(a)tk2msftngp13.phx.gbl... > All NT-only software must be Unicode-only. > > Otherwise, a) you force the OS to convert the strings each time b) you're > dependent on user's Control Panel setup c) localizing the app to Japanese and > other Far East is a nightmare. DBCS are one of the most nasty inventions in > computing. > > -- > Maxim Shatskih, Windows DDK MVP > StorageCraft Corporation > maxim(a)storagecraft.com > http://www.storagecraft.com > > <zzz> wrote in message news:uLevXK8GGHA.3056(a)TK2MSFTNGP09.phx.gbl... > > Yes, it works, thank you. I believe the unicode is unnecessary, > > unless one wants to work with L"" strings... > > thanks. > > > > > |