More GetLocalTime

[Synfire]

theiod,

Don't confuse the console with the DOS operating system. Mark Jones was explaining that the old DOS/COM and MZ/EXE are 16-BIT code whereas Windows PE/EXE code is 32-BIT. The DOS operating system (unless maybe FreeDOS or some other newer versions) are almost always 16-BIT real mode operating systems and run 16-BIT executables. On Windows the "DOS" box you get is a console window which, on versions after Win98 (iirc), simply emulates the old DOS command line. There is a LINK.EXE which builds 16-BIT DOS/COM and MZ/EXE programs and he was mearly turning you on to this.

As for not using MASM32, is there a reason that you don't wish to use it? You can create windows applications without MASM32 but it makes things a lot easier, and as you mentioned you are "an assembly newbie". I'm personally not sure how to build Win32 Applications without using the PlatformSDK (if there is a way), in nasm it's very easy as my NASM32 package basically encapsulates this method to keep the download size down. If you look in the \MASM32\Examples\exampl08\masm1k directory you can see how to build applications using the import libraries alone (which doesn't require MASM32 but does require you to have a copy of the PlatformSDK). I did create a include file called K32BINC which can still be downloaded off of http://www.codegurus.org/~bkeller under the projects tab, but be forewarned that this method creates executables without an import section and on Win2K the PE Loader refuses to run any application that doesn't have an import section (on Win2K you have to at least have kernel32.dll loaded) so this isn't a really good method to develop anything you plan to release. I'm sure Hutch or one of the others could point you into a better method but I honestly don't use MASM a whole lot.

Regards,
Bryant Keller

[hutch--]

theiod,

Bryant is correct here, a package that puts many things to gether for you is a far better proposition that trying to nut all of this stuff out the hard way. Most of the older programmers can write applications in most of the available assembler and can write them in bare mnemonics but its a very hard road to start with so its not really recommended.

The version of ML you are using ML.EXE 6.15 is a very good version that you can simply place in the MASM32 BIN directory instead of the 6.14 version that is there at the moment and it will work fine for you.

Once you are familiar enough with 32 bit assembler instructions and windows architecture and API calls, its no big deal to work in other assembler and some of them are very good. I personally like POASM and GAS but NASM is very well respected, FASM has a big following and GoAsm is a very well written tool with classy accessories. Once you are up and going properly, you can write what you like in whatever tool you like.

[MichaelW]

theiod,

Starting with the source that Ossa posted, this shows how to do it in straight MASM code, without any libraries (import or static) or includes. AFAIK the Microsoft linker is dependent on libraries, so I used GoLink (http://www.jorgon.freeserve.co.uk/) to perform the linking step.

Code Select Expand



; test.asm

.386
.model FLAT, STDCALL
option casemap:none

; Necessary structure definition

SYSTEMTIME STRUCT
  wYear             WORD      ?
  wMonth            WORD      ?
  wDayOfWeek        WORD      ?
  wDay              WORD      ?
  wHour             WORD      ?
  wMinute           WORD      ?
  wSecond           WORD      ?
  wMilliseconds     WORD      ?
SYSTEMTIME ENDS

; Necessary equates

NULL equ 0
LOCALE_USER_DEFAULT equ 0400h
STD_OUTPUT_HANDLE equ -11

; Prototypes for the called kernel32.dll functions

GetLocalTime PROTO :DWORD
GetDateFormatA PROTO :DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD
GetDateFormat equ GetDateFormatA
GetTimeFormatA PROTO :DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD
GetTimeFormat equ GetTimeFormatA
GetStdHandle PROTO :DWORD
WriteFile PROTO :DWORD,:DWORD,:DWORD,:DWORD,:DWORD
ExitProcess PROTO :DWORD

; Prototypes for the included MASM32 library procedures

StdOut PROTO :DWORD
StrLen PROTO :DWORD

; String lengths

MAX_DATE_LEN EQU 20
MAX_TIME_LEN EQU 15

; Format strings

.data

  szDFormat db "ddd',' MMM dd',' yyyy'", 0Dh, 0Ah, "'", 0
  szTFormat db "hh':'mm':'ss tt'", 0Dh, 0Ah, "'", 0
 
  szDateTitle db "Date", 0
  szTimeTitle db "Time", 0

; Run time data

.data?

  stCurTime SYSTEMTIME <>
  szDate db MAX_DATE_LEN dup (?)
  szTime db MAX_TIME_LEN dup (?)

; Start code

.code
start:

    ; Get time
   
    invoke GetLocalTime, addr stCurTime

    ; Convert

    invoke GetDateFormat, LOCALE_USER_DEFAULT, NULL, addr stCurTime, addr szDFormat, addr szDate, MAX_DATE_LEN
    invoke GetTimeFormat, LOCALE_USER_DEFAULT, NULL, addr stCurTime, addr szTFormat, addr szTime, MAX_TIME_LEN

    ; Output

    invoke StdOut, addr szDate
    invoke StdOut, addr szTime

    ; Exit

    invoke ExitProcess, 0

; ---------------------------------------------------
; These are copies of the MASM32 library procedures.
; ---------------------------------------------------

StdOut proc lpszText:DWORD

    LOCAL hOutPut  :DWORD
    LOCAL bWritten :DWORD
    LOCAL sl       :DWORD

    invoke GetStdHandle,STD_OUTPUT_HANDLE
    mov hOutPut, eax

    invoke StrLen,lpszText
    mov sl, eax

    invoke WriteFile,hOutPut,lpszText,sl,ADDR bWritten,NULL

    mov eax, bWritten
    ret

StdOut endp

OPTION PROLOGUE:NONE
OPTION EPILOGUE:NONE

align 4

StrLen proc item:DWORD

  ; -------------------------------------------------------------
  ; This procedure has been adapted from an algorithm written by
  ; Agner Fog. It has the unusual characteristic of reading up to
  ; three bytes past the end of the buffer as it uses DWORD size
  ; reads. It is measurably faster than a classic byte scanner on
  ; large linear reads and has its place where linear read speeds
  ; are important.
  ; -------------------------------------------------------------

    mov     eax,[esp+4]             ; get pointer to string
    push    ebx
    lea     edx,[eax+3]             ; pointer+3 used in the end
  @@:     
    mov     ebx,[eax]               ; read first 4 bytes
    add     eax, 4                  ; increment pointer
    lea     ecx,[ebx-01010101h]     ; subtract 1 from each byte
    not     ebx                     ; invert all bytes
    and     ecx,ebx                 ; and these two
    and     ecx, 80808080h
    jz      @B                      ; no zero bytes, continue loop

    test    ecx,00008080h           ; test first two bytes
    jnz     @F
    shr     ecx,16                  ; not in the first 2 bytes
    add     eax,2
  @@:
    shl     cl,1                    ; use carry flag to avoid branch
    sbb     eax,edx                 ; compute length
    pop     ebx

    ret     4

StrLen endp

OPTION PROLOGUE:PrologueDef
OPTION EPILOGUE:EpilogueDef

; End code

end start


And a batch file to assemble, link and test it:

Code Select Expand


if exist test.obj del test.obj
if exist test.exe del test.exe
ml /c /coff test.asm
pause
GoLink /console test.obj kernel32.dll user32.dll
pause
test
pause


For this small simple app the source file more than tripled in size (3878 bytes versus 1024 bytes). Had I not been able to get the necessary definitions and prototypes from the MASM32 include and source files I would have had to spend a significant amount of time searching through documentation and header files, and writing and testing support code.

[theiod]

The only reason I needed to use straight masm 615 was that this one was part of a design requirement. This time I was able to talk my way out of it, but we'll see if  it continues that way.

You guys are right, I've been in windows too long I keep forgetting the difference between the console, and DOS.

[Mark Jones]

I've written about a dozen 32-bit masm 6.15 programs that run in DOS.

Is there something else you are talking about?

Well apparently I'm confused. As long as you understand... :lol