Ralf's Int List didn't give any details on file naming strategy
using by the temp file generator.

It looks like it's always a 8 character filename with
no extension and I'd like to use it but have to make sure that's it indeed
always has 8 characters exactly.

Thanks.

; temp.asm Create a temporary file with a unique name,
; it must be deleted manually
;

..model small
..stack 200h ; 512 byte stack
..data

path db 'c:\borlandc\files\',13 dup(0)

..code

start:
mov ax,@data
mov ds,ax
mov ah,5ah

; Bitfields for file attributes: Decimal Equivalent
; Bit(s) Description (Table 01420)
; 7 shareable (Novell NetWare)
; 7 pending deleted files (Novell DOS, OpenDOS)
; 6 unused
; 5 archive 32
; 4 directory 16
; 3 volume label
; execute-only (Novell NetWare)
; 2 system 4
; 1 hidden 2
; 0 read-only 1

mov cx,00100000b ; file attributes, archive bit set
mov dx,offset path
int 21h ; ax contains the file handle

exit:
mov ax,4c00h
int 21h

end start
Posted on 2004-02-15 04:57:36 by skywalker
Why don't you just move to Win32 coding? Or move to a DOS-asm board?
I certainly can't remember any of the old DOS stuff, and I don't want to anyway.
Why do you make things so hard on yourself, by using an archaic unsupported junk OS?
Posted on 2004-02-15 06:07:48 by Henk-Jan

Why don't you just move to Win32 coding? Or move to a DOS-asm board?
I certainly can't remember any of the old DOS stuff, and I don't want to anyway.
Why do you make things so hard on yourself, by using an archaic unsupported junk OS?


This section is also for non Win 32 questions.

Why does it bother you that I post these questions.

Extensive Win 32 code isn't made available by MS.

They are plenty of newsgroups and places to get help with it though and that's great.

I have a number of programs written that run great right up to Windoze XP in a DOS box.
It may shock you, but there are a lot of people who still go to a command prompt.

Why ? There is a heavy price to pay for the fancy GUI interface. Speed and to a lessor extent size.
Some well written "DOS stuff" apps will "blow the doors off" off even the best Win 32 apps.

Re
Take care.
Posted on 2004-02-15 06:29:40 by skywalker
I write my commandline programs in Win32 aswell. Why? There's a heavy price for 16 bit code, and for the sandbox which virtualizes certain instructions, etc, etc.
Any well-written console Win32 apps will "blow the doors off" any well-writen "DOS stuff".
Posted on 2004-02-15 07:17:20 by Henk-Jan

I write my commandline programs in Win32 aswell. Why? There's a heavy price for 16 bit code, and for the sandbox which virtualizes certain instructions, etc, etc.

That depends on the OS and the code.

Any well-written console Win32 apps will "blow the doors off" any well-writen "DOS stuff".


I won't embarrass you with a file finder that is at least 5X faster than any Win 32 stuff I have seen.
And if I use a ramdrive, it runs in an eyeblink.

:-)
Posted on 2004-02-15 07:29:21 by skywalker
I've been coding Win32 and DOS long enough to know that Win32 is always faster than DOS, especially DOS running in an NT DOSbox.
It just shows that you haven't seen enough of Win32 yet. But if you want to remain closed about this, go ahead, your loss.
Posted on 2004-02-15 08:40:38 by Henk-Jan
andrew kennedy,

If you working on a big 16-bit DOS project, you will face the problem of segmentation which makes slower your code.

Another fact, 32-bit registers (which means a DWORD) have two times the capacity of 16-bit registers.

You can't claim that 16-bit code runs faster than 32-bit code.
Posted on 2004-02-17 05:00:06 by Vortex

andrew kennedy,

If you working on a big 16-bit DOS project, you will face the problem of segmentation which makes slower your code.

Another fact, 32-bit registers (which means a DWORD) have two times the capacity of 16-bit registers.

You can't claim that 16-bit code runs faster than 32-bit code.


I never said all 16 bit code runs faster. For the programs I have written so far, 16 bit regs have been more than enough. I would have more room if I needed it by using 32 bits regs but would pay a 1 opcode penalty for using them in 16 bit code.

So far my biggest program is around 2000 bytes. I can fit 2 -3 of my programs in one cluster where a Win 32
would be lucky to fit in one.

I would be glad to test my file finder program against anything someone can write in 32 bit and test it.
I have turbo profiler which allows speeding up the clock for some pretty accurate timings.

Tqke care.
Andy Kennedy
Posted on 2004-02-17 06:36:06 by skywalker
So far my biggest program is around 2000 bytes. I can fit 2 -3 of my programs in one cluster where a Win 32
would be lucky to fit in one.


Size says nothing about speed, other than that most size-optimized programs are considerably slower than their speed-optimized cousins.
Oh, and you can not fit more than one file in one cluster by definition, so you are just wasting more space than us Win32 users :)
At least our extra 'waste' of space translates in faster programs.
Oh, and the smallest working Win32 program is about 700 bytes. It's not THAT big a deal... 2k or 2.7k, I wouldn't bother.
64k or 64k? I don't even notice (gets lost in the roundoff).

I would be glad to test my file finder program against anything someone can write in 32 bit and test it.
I have turbo profiler which allows speeding up the clock for some pretty accurate timings.


Aren't file finders completely I/O-limited anyway?
Besides, since you have never even needed 32 bit registers, an your biggest program is 2000 bytes, perhaps you should open your mind and listen to some more experienced programmers?
Posted on 2004-02-17 07:17:26 by Henk-Jan

I won't embarrass you with a file finder that is at least 5X faster than any Win 32 stuff I have seen.

Hm, what kind of file finder? And what have you compared it with? I can't really think of a reason why a dos app would be faster for file finding than a win32 app, perhaps except if you do your own filesystem handling code... which is sorta a no-no these days. But would be interesting to see if you were right. Then again, if you just ran a normal win32 file search dialog and your search app afterwards in a dos box... heh.


And if I use a ramdrive, it runs in an eyeblink.

Anything in a ramdrive would run in an eyeblink - especially since ramdrives are usually pretty limited in size ;). If you meant a disk cache, that's something else... good thing that windows has a built-in disk cache that blows the door off smartdrv :)

But well, it *would* be interesting to see a dos application beating win32 this way. How should it be timed, though? Raw DOS vs. raw NT? Using smartdrv under DOS? Or perhaps timing the dos under a NT dos box?


I have turbo profiler which allows speeding up the clock for some pretty accurate timings.

You don't need to mess with the clock to get rather accurate timings under win32 - there's the high-performance multimedia timer jiggidyzag :)

As for size... ho humm. Doesn't really matter, does it? Cluster sizes are at least 4k on typical win32 installations, and even on a (by today's standards) ridiculously small 1gig drive, having your executables weigh at 32k (rather huge for a win32 assembly (or C without runtimes) app, normal size for a small win32 C tool) isn't a terrible disaster - it's a different story with multi-meg exes though.

Well, if you want to do 16bit code, that's all fine and dandy :). But you might want to play around a bit more with win32 and see what it has to offer you - you might be in for a pleasant surprise :)
Posted on 2004-02-17 10:58:48 by f0dder
Why is everyone so upset about 16bit apps? True, they are bound to be slower that win32 stuff, but as an advantage they are much better when making utilities and antiviruses. That way you can put the program in a boot disk -win32 apps would never run like that. :)

As for the original question, I guess it's safe to assume the filename is in 8.3 format -win32 temp files are too.
Posted on 2004-02-17 13:26:33 by QvasiModo

That way you can put the program in a boot disk -win32 apps would never run like that.

Look out for WDOSX... there's at least one other dos extender with PE loading and win32 subset support, which is actually used in... ta-da... an antivirus package :)
Posted on 2004-02-17 13:38:50 by f0dder
:grin:

f0dder - 1
QvasiModo - 0

Oh, well... we still have the nostalgia reason ;)
Posted on 2004-02-17 13:40:42 by QvasiModo
I'm glad I've forgot most of the 16bit stuff - it was rather limiting and not very fun, and having to memorize the interrupts and codes (or constantly look them up in references) was tedious. Yay for the ease & power of 32bit flat memory model, and for symbolic function names :D - not to mention the lack of protection & multitasking in DOS.

But hey, if you can write a faster file searcher, there might be *some* benefit of using 16bit code still :p
Posted on 2004-02-17 13:52:58 by f0dder

Why is everyone so upset about 16bit apps? True, they are bound to be slower that win32 stuff, but as an advantage they are much better when making utilities and antiviruses. That way you can put the program in a boot disk -win32 apps would never run like that. :)

As for the original question, I guess it's safe to assume the filename is in 8.3 format -win32 temp files are too.


Most of my 16 bit apps handle long file names with no problems, there are Win 95 + interrupts I used for that.
I wrote to handle up to 6 letter extensions, if they used more that I think they must not be creative.

If someone is using pre-Win 95 it's probably cuz their short on cash. :-)

Thanks for not judging me.

Andy Kennedy
Posted on 2004-02-17 14:24:30 by skywalker

:grin:

f0dder - 1
QvasiModo - 0

Oh, well... we still have the nostalgia reason ;)


I have been modifying some Win 32 code and compiling it. You still have to do it from a DOS box though.
I was looking thru my MASM32 directory for the .html tutorials and didn't find the ones from a previous
package. Just a few for optimizations and other stuff.

Learning to use masm wasn't as hard as I thought. Seems like more commands than using Tasm 52.

Outta here.
Posted on 2004-02-17 14:28:55 by skywalker
Most of my 16 bit apps handle long file names with no problems, there are Win 95 + interrupts I used for that.
I wrote to handle up to 6 letter extensions, if they used more that I think they must not be creative.


With long filenames the concept of extensions is lost. The '.' is just another char in the filename... Sorta like on Amiga (erm yes in 1985), where you had prefixes rather than suffixes... Eg:
mod.my fantastic 4-track song"
Such stuff would probably crash your application? :)
Not to mention things like "the.latest.uber.warez-El1t3gr00p.zip"? :)

Besides that, I don't really see the point in writing 'DOS' applications that require Win95 or higher. Surely native Win32 apps are faster.
Posted on 2004-02-17 14:47:04 by Henk-Jan
Henk-Jan,

You wrote:

>Oh, and the smallest working Win32 program is about 700 bytes.

You should keep up the file size at a minimum of 1024 bytes to avoid some compatibility problems.
Posted on 2004-02-18 05:07:26 by Vortex
You should keep up the file size at a minimum of 1024 bytes to avoid some compatibility problems.


Yea I know, Win9x has a broken PE loader. Then again, Win9x is dead.
Posted on 2004-02-18 05:39:27 by Henk-Jan



Yea I know, Win9x has a broken PE loader. Then again, Win9x is dead.


If only that were true life would be alot easier :alright:

I broke TBPaint on Win9x once and got 100+ emails over 3 days bitching about it.
Posted on 2004-02-18 05:57:01 by donkey