sorry,my home page should be this :
and this is the demo cutting files using file-mapping.I did know it had some errors but woked very good by my test.
Posted on 2001-11-16 05:43:47 by smallwaves
Hutch-- and all,

Attached is a zip file with jacts.asm clock.ico &
rsrc.rc for a program I use at least once a day to
remind me to get up and do "something" or watch
a TV program. It was the second asm program I
finished but the one that got me started in MASM32. Include this with 7.0, or just look and
put it to use if handy.

I wanted something like this but the only freeware
utilities I could find were written in VB and
required this DLL or another and ended up as
multi-megabyte downloads. This ends up as a 12K
exe file and hardly registers on the CPU
utilization indicators.

It uses the DateTimePicker controls to set a date
& time for an "alarm" or you can set a certain
number of hours/minutes/seconds till the alarm
sounds. The alarm can be any sound which can be
handled with the PlaySound API. A stopwatch
feature is also available.

Posted on 2001-11-16 14:12:25 by farrier
Hutch: could you add these constants to They are winsock 2 specific and used for the function WSASelectEvent. I couldn't find them in the current

FD_OOB_BIT equ 2
FD_QOS_BIT equ 6


lNetworkEvents dd ?
iErrorCode dd FD_MAX_EVENTS dup (?)

Posted on 2001-11-16 14:47:31 by Thomas
here hutch, catch. It was very easy to convert the C source to asm,
it took a lot longer to convert the htmlhelp.h to Icky.
Feel free to include and htmlhelp.lib as part of standard
masm32 distro ( isn't 100% complete though, there
was a struct I didn't convert 100% and such).

And of course include the app as a demo. Don't go changing around
the sources though, they are as they should be. I used relative
paths, and people will just have to learn to use INCLUDE and LIB
and deal with it... or at least take the time to edit the source and
put in the semi-absolute paths. They'll need source editing anyway
to point to a .col or .chm file.

Have fun.
Posted on 2001-11-16 15:33:08 by f0dder
Geeh, it's just too easy to remember to forget to actually attach
your stuff, giggle.
Posted on 2001-11-16 15:35:31 by f0dder
How about adding an _WINDOW_INC equ so we have a standard way of checking to see if its installed. So far ive just been checking for WM_CREATE. Just a suggestion.
Posted on 2001-11-16 16:16:39 by ChimpFace9000
Posted on 2001-11-16 16:31:42 by f0dder

I have seen this type of stuff in VB coding but I just don't see the point of a dead equate in the file when the easiest way to see if its there is to cheack at the top of the file.

Posted on 2001-11-16 17:10:35 by hutch--
El hutchesson, what is this thingy chimpface wants? Details, please.
Posted on 2001-11-16 17:28:22 by f0dder
What i mean is, say you have one include file that you have for all you asm files. And with that inc flie you need the windows inc file to be included too. So in case you forget to put an include at the top of your asm file you put this in you inc file...



Then if isnt included, _WINDOW_INC would not have been defined, and then would be included. If _WINDOWS_INC is defined, then isnt included.

Did that make sense?
Posted on 2001-11-16 17:43:33 by ChimpFace9000
Yes, it made sense, and I actually believe it's pretty useful... that
way you don't get screwed if you include header files multiple times.

But oh well, since is as monolithic as it is :/, it's not too
much of an issue.
Posted on 2001-11-16 18:06:45 by f0dder
Btw everybody, feel free to comment on the hhlookup... I see it's
been downloaded 8 times... feedback! :grin:
Posted on 2001-11-16 20:43:24 by f0dder
f0dder: I haven't had the chance to actually try it but thanks for converting the headers.. I definitely plan to create htmlhelp for my HTTPFT program.

Thanks :alright:

Posted on 2001-11-17 03:47:56 by Thomas

After setting the inc/lib directory paths and adjusting the HHFILE textequ (using single backslashes instead of two in the filepath..and pointing it to my platsdk.col file), and also putting uuid.lib in the same folder as the .asm was in (it wouldn't pick it up from my libs dir)...THEN it works GREAT !! :alright:

There's lots of interesting code you've whipped up in there too. I am again, inspired!

BTW: In your earlier post you mentioned your use of relative paths for the incs/libs...


It wouldn't take. How should that work?
Posted on 2001-11-17 06:26:10 by gscundiff
The big problem with the relative paths is that hutch uses an old
win3.x function for spawning apps, instead of CreateProcess, and
thus cannot specify an environment block to ml.exe. This means
ml.exe in effect ignores your INCLUDE and LIB paths, and you have
to specify the semi-absolute paths as (almost?) all masm32 examples do.
Hutch defends this by "you can always edit the batch files included
with masm32". True. But still a bit cheesy, and I would still need
to specify some paths myself, as the environment variables aren't
there (well, it's some months since I played around with this, and
according to my memory, the env. variables weren't present).
All there is to it is to GetEnvironmentStrings(), use that in CreateProcess,
and use CreateProcess instead of WinExec (it's not too hard to
write a wrapper around CreateProcess that does this and is as
easy to call as WinExec).

That's why I use editplus (or masmed) for editing, and a cmd.exe
for calling ml.exe and link.exe myself (usuall through batch files).
If you're on win9x, you must edit autoexec.bat to include
SET INCLUDE=c:\masm32\include
SET LIB=c:\masm32\lib
(or add to them with semicolon-separation if you already have include
and lib environments), and then reboot to take effect. If you open
a, you can also set these variables temporarily, to
test out before you reboot.

If you're on nt/2k/xp, go to system properties, advanced tab, environment
variables, and set INCLUDE and LIB in the "user variables for <user>".
You might need to close cmd.exe and other apps and open again
for them to use the new env variables, but you do not need to reboot.

After you have done this, open a cmd.exe or and
try my mk.bat. If it works, life is jolly :).
Posted on 2001-11-17 08:35:15 by f0dder
By the way, the double-backslashes work fine on my system :).
Yeah, they should be changed to single-backslashes... silly me.
But it *works* on my system. Weird.

It's also weird you had to put uuid.lib in your folder... it ought to
be picked up automatically... perhaps it's not included in the masm32
libs? I have deleted the masm32 libs, and now exclusively use the
libs from platformsdk. I realized I had libs from masm32, lcc, vc++,
and platformsdk... and this was taking too much space. So I just
deleted all the crusty old libs and set up all my tools to use platformsdk.
"The latest and the greatest" :).

The only part of masm32 I really use now are the header files.
And sometimes I look through the examples, although that's not
very often either. But I'm still happy that hutch and iczelion care to
put this tremendous effort into this package. Especially the whole
header file mess ( structure conversion... bloody boring
to do by hand).

I don't particularly enjoy the monolithic nature of, but
with the processor I have, it's not *too* much of a problem. I pity
people with slower boxes though.
Posted on 2001-11-17 08:42:06 by f0dder

Thanks for the explanation on relative paths. I'll definately setup my system that way now.

I've encountered problems with WinExec not displaying ComboBox text, so I've been using ShellExecute instead. And what's the deal with CreateProcess (or multiple-CreateProcess) and the way it leaks memory? A big problem after several dozen builds with IDE's that use it...User Resources dive like the Titanic!

I did have uuid.lib in my libs directory. It was from Hutch's pkg 953kb-12.02.97. I also tried the newer one from the PSDK 1237kb-07.26.01 but it said it couldn't find either one. So I just slapped it into the same folder the .asm was in. Haven't bothered to suss out why yet.



I'm still too green in Win32asm to contribute much of anything to your v7 package, but I thought I'd try something at least...

It's a snippet I picked up from some LordRhesus code that uses AppendMenu to setup a Right-Click dropdown menu in a program.
Posted on 2001-11-17 12:12:25 by gscundiff
Hmm, CreateProcess leaking? You might want to CloseHandle
on pi.hProcess and pi.hThread if you don't use them, that might
be the cause of the leaks.

ShellExecute is okay, though it doesn't offer as much flexibility as
CreateProcess. It's *very* good for launching "files" though, because
it handles filetype associations.
Posted on 2001-11-17 12:20:39 by f0dder
hi hutch,
could you include in your package a separate linker for 16 bit dos programs, and an option in IDE what kind of project to build, dos or win executable? that would make life alot easier to begginers like me who want to write asm DOS programs for learning purposes (all books about asm programming i have deal with writting proggies for DOS not for win32).
Posted on 2001-11-17 15:23:35 by Unregiztered

A little knowledge is a dangereous thing, if you really want to use the environment for handling the paths of the LIB and INCLUDE directories, you take advantage of the Virtual Machine component of all of the 32 bit versions of windows and set the path in the batch file you choose to use to build the project.

This way you can avoid the exact problem that is addressed in the semi absolute paths in MASM32, getting the wrong version of LINK, the wrong versions of the libraries and the countless errors that follow from doing so.

Putting these paths in the autoexec.bat file restricts the user to one programming environment where MASM32 was designed specifically to co-exist with others and the only safe way to do this is to set the paths in the source file.

There are multiple way of building files under masm, the problem with non standardisation is that few people can get examples going when they are built in ways that are not documented properly. With the standardisation in MASM32 it allows code to be passed around without all of the associated problems of not finding the appropriate binaries, libraries, includes, nmake and other compatibility problems.

The big problem with the relative paths is that hutch uses an old win3.x function for spawning apps, instead of CreateProcess, and thus cannot specify an environment block to ml.exe.

A little investigation will show that WinExec is directly mapped to CreateProcess within the appropriate system DLL. If I remember correctly, the demo code you sent me some time ago to manipulate the environment block rebooted my machine when I ran it so this type of "advanced" programming is the type I avoid.

The advantage of the technique I use in MASM32 is that it is reliable and it is not subject to variation across different versions of windows.

The other problem with this approach is that ML.EXE can use an environment set at the command prompt so messing around with unreliable code is no gain here.

Posted on 2001-11-17 17:22:52 by hutch--