Sorry for the late reply... i was falling into a deep sleep :)


herman, why is it you call command.com or cmd.exe to spawn external processes? It ought to be superfluous (unless you're doing it to use shell commands like "copy", in which case you really ought to write your own routines :)).


Well.. I had program (hll) that i need to maintain for some client. It has the capability to do a backup from inside the program. The backup procedure use pkzip and pkunzip. So it runs command.com by default.

It open a a dos window and leave it open after finish and it waits for users to close that window before return to the program. I can solved it use a pif file and checked "close on exit".
But this was the problem is. First, I want my own windows in that program as a message for user (no dos window), also i don't want to create pif file for every computer (also for future sake) on my client side. So I need a tool for this. And then i becoming more involved for this particular tools... just a story :grin:

NaN
I am now on ME system and tried your latest program (2.1). The test program is the same with the last one i had posted, but i remove the #COFF and leave the #HEADER only. I had one message telling me that linker cannot build the lib.


LINK : fatal error LNK1104: cannot open file ""
trans2.inc
1 File(s) copied

Haven't try it on 2K, but any idea for this ?

Btw, I think soon this tools will become very handy and i am going to put this as one of my favorite tools :alright:

Regards
Posted on 2003-01-05 21:03:04 by HermanT
herman, it's a bit late and I'm not sure I understand you correctly,
bear over with me. But CreateProcess will allow you to force creation
of a new console, reuse existing console (and yes, GUI mode apps
*can* create consoles), or run without a console at all. So if console
management is why you use cmd.exe/command.com, then you might
not have to.

NaN, using "nop procs" to test stuff like that might not be a good
idea, since NOP is used for padding. use rdtsc or something :)
Posted on 2003-01-05 21:25:30 by f0dder

NaN,

An obvious suggestion if you want synchronous operation with command line tools is to write a batch file that does the work you want. It does not work with GUI apps with a message loop but a linear console app works fine.

Regards,


You would think this to be true, but at least on my Win98SE it isnt true. This is how i ran into all the problems that be. I origionally did this, but the LIB.EXE wouldn't work cause the ASM's (on file) were not closed yet (an assumption) from the previous ML.EXE command in the batch file. I dont know why it didnt work.. but the same batch file works if ran manually :confused: . However, from trial and error this is what i found happening. :me_dont_get_it_either:

I acutally modelled the 'custom' batch file after your MAKE.BAT from the M32LIB dir ( :) you've been an excellent resource ;) )

HermanT,

I have no clue what your error is. I dont know how or why the LINKER got into this picture. There is absolutely no calls to the linker!! This error must be on you account... I cant offer help with out more idea what your trying to do.. /me: shrugs

f0dder,

Once again sage advice, thanx. Its the little things you seem to pick up on most ;) . I will do some trials to see if all holds true.. I appreciate your help.

Everyone,

Please try it out, and give me feedback. Also let me know if your ok with the 'private' proceedure business. I am, but that may not mean everyone else is ;) . Its a mild overhead for people wanting to include private proc's...
Posted on 2003-01-05 22:24:43 by NaN
From more tiral and error, i discovered f0dder's concerns to be NULL & Void ;)

Everything works as it should...

As well, i also discovered that the private directive is of no *real* concern. Even though there is no include generated, if you knew of it, you could make a PROTO manually and still call upon the function from the lib. This is really no surprise, cause its been an age-old problem with masm, well as far as i remember anyways.

However, adding multiple funtions/per scope is not a problem with the TEXTEQU solution.

So are people happy with this version? Or should i add more 'fixes'??



:alright:
NaN
Posted on 2003-01-05 22:35:52 by NaN

herman, it's a bit late and I'm not sure I understand you correctly,
bear over with me. But CreateProcess will allow you to force creation
of a new console, reuse existing console (and yes, GUI mode apps
*can* create consoles), or run without a console at all. So if console
management is why you use cmd.exe/command.com, then you might
not have to.


Yes i know it's a bit late.. sorry :)
No, it's not cmd.exe/command.com. What i'm after is the additional options switch /C. And i cannot pass this switch into createprocess cause it is being recognize as a file. It simply gives me an error "file not found". So i have to pass cmd.exe/command.com itself into the createprocess. For the whole story will bored you to death :grin:

NaN
I have no clue what your error is. I dont know how or why the LINKER got into this picture. There is absolutely no calls to the linker!! This error must be on you account... I cant offer help with out more idea what your trying to do.. /me: shrugs


I find the problem now, i have a path to "e:\masm32\bin" in my system :grin:
Now it's ok. But i only find the inc file so you're not making the lib anymore, is this true ? And why it has problem if i have that path ?
I'll try this more, and let you know the result
:alright:
Posted on 2003-01-05 23:55:33 by HermanT
Herman, as i warned above, you shouldnt use \masm\include because it deletes the directory before you use it!!

I hope your not deleting your \bin directory ???

perhpas i should make a warnign MSG box in the next version, if it warrents it..


Your system path should include "x:\masm32\bin\" which the LIBM.exe should reside. From here in any directory calling "LIBM .\dir\file.asm .\newout" will genreate an output and copy it back to the calling directory..

Remember you dont need to use the optional output directory!! Without it uses TEMP as a swap area, ensuring a safety ;)

If you do use the optional output directroy, be wise, and specify a directory that is not of imporatnce, or make a new title for a directory to be created...

:alright:
NaN
Posted on 2003-01-06 00:07:26 by NaN
NaN, i think you misundertood what i meant.

My system already has a path to masm32\bin. And that's what causing the error. If i took away masm32\bin from the system path, it works.

OK I tried again base on your suggestion.
From dos-prompt window.
The masm32\bin is in the system path. I put LIBM into that directory. Then from my test program directory i call libm with

LIBM trans.asm

It happen again, error! W2K also gives me the same error.
I noticed from the console that you build the library, but the I don't get the .LIB file in my directory, only .INC
:confused:
Posted on 2003-01-06 00:56:35 by HermanT
NaN,


This makes no sense to me. If you want to ignore stuff inside coff blocks, then simply dont add the 'stuff'...?


You misunderstood me. I meant your tool should write stuff inside those blocks as a whole, regardless how many procs are inside.


Thomas,

thanks for pointing to bitRAKE's post (and my apologies to bitRAKE haven't given his reply the attention it diserved). The tool mentioned there seems to do what it is supposed to do.

Japheth
Posted on 2003-01-06 04:33:46 by japheth
It seems i was miss-understanding alot of stuff yesterday..

HermanT, I dont know what your doing, or what this 'error' is. You need to give me more to work with.

Show me your 'sample.asm' file. Show me the command line your using, and from what directory. Is the LIBM tool in the PATH= scope or not? (Im surprised you had to remover \masm32\bin, cause i recomend you add it ~ this tells me there is probably another LIBM on your system or something).

Is the 'ERROR' a crash, or is it and output from the tool? Or is it just your interpretation of how it responded?

With the following example:
;#HEADER START

.386
.model flat,stdcall
option casemap:none

include D:\MASM32\INCLUDE\kernel32.inc

;#HEADER END
.code

One proc uses ecx edi edx esi String:DWORD
Two PROTO :DWORD
NEST_NEXT TEXTEQU <endp> ; This could be placed in the header as well
nop
nop
invoke Two,1
ret

One NEST_NEXT

Two proc private String:DWORD
nop
nop
nop
nop
ret
Two endp

end

And LIBM in the \masm32\bin directory.
And PATH has this directory in it.
And the above example saved in my D:\test directory as test.asm
I run a commandline from a DOS window: LIBM test.asm

I get: TEST.LIB and TEST.INC in the current directory i called LIBM from.

Can anyone else confirm it is faulty on NT machines?? (LIBM v2.1)

Japheth,

You never mentioned if the solution above is ok for your needs? Is it?
The specific reply is found here...

NaN

Posted on 2003-01-06 17:04:37 by NaN
NaN,
Take your time as much as you need, no need to rush right ?:)
My sample program is exactly the same as the last test program i had posted, but here it is


;#HEADER START
.386
.model flat, stdcall ; 32 bit memory model
option casemap :none ; case sensitive

.Data
cMsg db 'Test',0
;#HEADER END


.Code
Clear PROC hWnd:DWORD
mov eax, 0
ret
Clear ENDP

Two PROC
nop
nop
ret
Two ENDP

End


I try again this time with your "test.asm"
1. save test.asm in D:\Temp (The only file in this directory)
2. change the code "include" in test.asm to point to my include directory
- include D:\MASM32\INCLUDE\kernel32.inc
replace with
- include E:\MASM32\INCLUDE\kernel32.inc
3. make sure the "E:\Masm32\Bin" is in my system path
4. put LIBM in "E:\Masm32\Bin"
5. from DOS window:
- D:\Temp>LIBM test.asm

Still error (both system - ME & w2k). It doesn't crash only error. Here is the screen shot.
Posted on 2003-01-06 23:04:43 by HermanT
Your LIB is not the LIB i got in my MASM32 package:

Your LIB.EXE is version : 5.12.8078

My LIB.EXE is version 5.00.7022 :rolleyes:

I have no clue where you got that version, or what makes it different???

Needless to say, this is the source of your problems. Figure out how your lib wants the param string, change my source, and compile yourself a LIBM for LIB 5.12.8078 version... As far as i can tell, this version of LIB is calling the linker to do its dirty work. Cause my version doesnt do any *noticable* linker calls. This is what had me so confused when you kept reporting this error... :confused:

Sorry i cant be of any more help than this...
(as well you have the 8.15 assembler which i dont, but i doubt this is any problem)

:stupid:
:NaN:
Posted on 2003-01-06 23:13:32 by NaN
NaN,

to answer your question: "not perfectly".

The reasons are:

- my first need was to compile a generated file with 6500 stub functions. For that your tool would be great. But "unfortunately" due to "progresses in mind" I no longer need to generate this file :) .

- the more general purpose of such a function - eliminating unused functions from code - I cannot achieve with your tool :( . Thats because of my "oop model" (if I am allowed to call so my "quick and dirty solutions" without insulting yours and Thomas') doesnt implement name mangeling. So I put each class in its own source file, and naming private methods for example: "OnCommand". This aproach requires using "option proc:private", so that the linker doesnt complain about duplicate symbols. But as you see, this is incompatible with your tool.

The better approach for that is the "coff editing" tool from bitRAKE's link. But it requires at least one (macro) line between the procs. Thats not too bad and it works, but Im still hopeing for a solution without any source code changes.

But hey, writing such a tool is fun, so you are lucky :) .

Japheth
Posted on 2003-01-07 03:57:09 by japheth