Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

.ASM file in sources

8 views
Skip to first unread message

David F.

unread,
Nov 19, 2009, 7:37:12 PM11/19/09
to
DDK 3790.x

When I add an .asm file in sources I get a failure that it doesn't know how
to build it.

I don't really care about that, what I really want is the .obj from the .asm
(which I can build separately) to be included in the lib. With other lib
programs, they typically give + and +- options to add .obj to existing .lib
files. I didn't see such an option when running "lib" at the command prompt
in the build environment. Is there a way to add the .obj to a .lib
(DRIVER_LIBRARY) either in SOURCES file or via command line without
affecting the .lib built with the other .c files ?

TIA!!

David Craig

unread,
Nov 19, 2009, 7:49:41 PM11/19/09
to
Show us your sources file. I seem to remember a different sources line for
assembly.

"David F." <df2...@community.nospam> wrote in message
news:72FDD491-C1AA-4840...@microsoft.com...

David F.

unread,
Nov 19, 2009, 9:28:26 PM11/19/09
to

----- MYSOURCES.DEF ----

MAJORCOMP= ntos
MINORCOMP= acme
# support running on SMP machines (DO NOT USE)
# NT_UP= 0

INCLUDES=x:\libs\inc

#
# determine DDK
#
C_DEFINES=/DWIN_DDK_BUILD

!if "$(_BUILDARCH)"=="AMD64"
C_DEFINES=$(C_DEFINES) /DDDK_AMD64
!elseif "$(DDK_TARGET_OS)"=="WinXP"
C_DEFINES=$(C_DEFINES) /DDDK_XP
!elseif "$(DDK_TARGET_OS)"=="WinNET"
C_DEFINES=$(C_DEFINES) /DDDK_2K3
!elseif "$(DDK_TARGET_OS)"=="Win2K"
C_DEFINES=$(C_DEFINES) /DDDK_W2K
!else
C_DEFINES=$(C_DEFINES) /DDDK_NT4
!endif

----- SOURCES ----

!INCLUDE x:\MYSOURCES.DEF

TARGETNAME=fsup
TARGETTYPE=DRIVER_LIBRARY

# set warning level for this target
MSC_WARNING_LEVEL=/W3 /WX /FR /FAcs

# build conditional defines
C_DEFINES=$(C_DEFINES) /DASM_SUB

# include paths
INCLUDES=..\..;$(INCLUDES)

# put it in a directory
TARGETPATH=..\..\ddk\$(DDK_TARGET_OS)

# source files for build
SOURCES=\
f1.c \
f2.c \
f3.c \
f4.c \
a1.asm


"David Craig" <dri...@noemail.noemail> wrote in message
news:%23zhPZtX...@TK2MSFTNGP04.phx.gbl...

David F.

unread,
Nov 19, 2009, 10:14:51 PM11/19/09
to
To manually add an obj to a lib the following works:

lib libfile.lib objfile.obj


"David F." <df2...@community.nospam> wrote in message
news:72FDD491-C1AA-4840...@microsoft.com...

<snip>


> what I really want is the .obj from the .asm (which I can build
> separately) to be included in the lib. With other lib programs, they
> typically give + and +- options to add .obj to existing .lib files. I
> didn't see such an option when running "lib" at the command prompt in the
> build environment.

<snip>

David Craig

unread,
Nov 20, 2009, 12:47:57 AM11/20/09
to
That explains the problem. You need to specify that file in a i386_SOURCES
directive.

"David F." <df2...@community.nospam> wrote in message

news:D6D2D2A1-3216-4F1C...@microsoft.com...

Tim Roberts

unread,
Nov 20, 2009, 2:11:14 AM11/20/09
to
"David F." <df2...@community.nospam> wrote:
>----- SOURCES ----
>
>!INCLUDE x:\MYSOURCES.DEF

It is bad practice to include absolute paths in your build procedures,
especially one with a drive letter. Use relative paths instead. Also, the
".DEF" extension is traditionally used for DLL import files. ".INC" is
traditionally used for makefile includes.

>TARGETNAME=fsup
>TARGETTYPE=DRIVER_LIBRARY
>
># set warning level for this target
>MSC_WARNING_LEVEL=/W3 /WX /FR /FAcs

Only /W3 and /WX are warning levels. /FR and /FAcs should be moved to
C_DEFINES.

># build conditional defines
>C_DEFINES=$(C_DEFINES) /DASM_SUB
>
># include paths
>INCLUDES=..\..;$(INCLUDES)
>
># put it in a directory
>TARGETPATH=..\..\ddk\$(DDK_TARGET_OS)
>
># source files for build
>SOURCES=\
>f1.c \
>f2.c \
>f3.c \
>f4.c \
>a1.asm

Assembler files must be placed in a subdirectory corresponding to the
architecture. Assuming your a1.asm file is an x86 file, move it to a
directory called i386, and change sources to:

SOURCES = \
f1.c \
f2.c \
f3.c \
f4.c

I386_SOURCES = \
i386\a1.asm

When you write the x64 version, you can add it as well:

AMD64_SOURCES = \
amd64\a1.asm
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

David F.

unread,
Nov 20, 2009, 12:09:06 PM11/20/09
to
Thanks - almost used those - but wanted to get it working first.

"Tim Roberts" <ti...@probo.com> wrote in message
news:vifcg51vbgevpco6m...@4ax.com...

Kalle Olavi Niemitalo

unread,
Nov 20, 2009, 5:59:21 PM11/20/09
to
Tim Roberts <ti...@probo.com> writes:

> Assembler files must be placed in a subdirectory corresponding to the
> architecture.

Is that documented? The page about SOURCES
http://msdn.microsoft.com/en-us/library/ms792148.aspx
doesn't say anything like that; on the contrary, it says:

"All files specified by this macro must be located in the
directory that contains the Sources file or in the parent
directory of the Sources file."

which would even seem to disallow an i386 subdirectory.
"Build Utility Limitations and Rules"
http://msdn.microsoft.com/en-us/library/ms792413.aspx
does mention SOURCES can list files in "the platform
subdirectory", but I didn't find anything that says
platform-specific files have to be placed in such a directory.

Tim Roberts

unread,
Nov 22, 2009, 11:44:45 PM11/22/09
to

I don't know. The final answer to all such questions is the source code,
which we have, in bin\i386.mk and bin\amd64.mk. For the x86, it looks in
i386 and ..\i386 for asm files. It doesn't look in ".".

Kalle Olavi Niemitalo

unread,
Nov 23, 2009, 1:51:02 PM11/23/09
to
Tim Roberts <ti...@probo.com> writes:

> I don't know. The final answer to all such questions is the source code,
> which we have, in bin\i386.mk and bin\amd64.mk. For the x86, it looks in
> i386 and ..\i386 for asm files. It doesn't look in ".".

Thanks. Could you also say which WDK version you checked?

Tim Roberts

unread,
Nov 25, 2009, 1:02:10 AM11/25/09
to
Kalle Olavi Niemitalo <k...@iki.fi> wrote:

I have 3790, 3790.1830, 6000, 6001.18001 and 7600 installed on this
machine, and it's the same on all of them. I know it has been this way
since the original NT 3.1 DDK, which happened to use a lot more assembler
code.

0 new messages