Search results for query: *

I take a somewhat different approach. The app that is run is simply a loader, it might go unchanged for years. It loads, looks around to find the version it's supposed to run and runs that. The real program is stored with a numeric extension rather than a .EXE, the loader simply finds the...

A bit of safety advice: When you're writing records to disk, always specify them as packed. Saves *LOTS* of headaches!

You can't access pixels in text mode. Everything is in the 80x25 mode.

Yeah, it's in the compiler messagaes. You can turn off all that .net crap.

I wouldn't leave the locking until last--that just about guarantees you will have problems. When dealing with a multi-user situation you must keep locks on your mind as you are writing it.

Hebbe's code is fine if you're using Turbo Pascal. I can definitely confirm it works on a Novell server, it should work on any server. However, my experience is that it does *NOT* work in a dos box of XP Pro. Don't give up on the locks--multi-user programs are *NOT* reliable without...

While the basics of your solution would work (no need to wait, just leave the file open. In fact there's no need to write anything.) it's horribly inefficient and it's just using the system's own locking facilities in another fashion. Quit trying to dodge the manual, lock it correctly...

You *CAN'T* implement your own locks that way--locking must be an atomic operation and check-if-clear-and-write-true is not atomic. While it's possible to do some of your own locking (if you wish to deny specific operations but permit others) at the heart of it you *MUST* use the...

>its just sharing files. I dont need messaging or anything, i >just need a database to be updateable on one comp and then >viewable on another. >Though I would like it to be maintainable so I guess the >messaging would be somthing Id have to look at in depth. If all you need is file...

Are you sure it's the same file? Note that you are using different names in the two routines!

No. In protected mode you can't absolute to a memory location, period--the only legal use of absolute is to put two variables on top of each other. You must build a pointer to it instead.

You have to use the initialization section rather than constant initialization when using the SegXXXX variables.

Instead of storing IOResult, simply read InOutRes instead. Same thing but it doesn't get wiped. Note that this will *NOT* work in Delphi, though. However, you don't really need $I- in Delphi, exceptions are so much better. As for error logs--you need to at least flush and commit (note...

$I has nothing to do with system interrupts. It has to do with I/O error checking. Turned on, I/O errors bomb the program. Turned off they are merely returned in IOResult.

So long as you stay in real mode, SegB800 and $B800 are the same thing. However, in protected mode, $B800 is a runtime error. I much prefer to work in protected mode.

Run a leak tester. You're probably not freeing something. You might want to try: http://v.mahon.free.fr/pro/freeware/memcheck/

monoscreen : full_screen ABSOLUTE $b000:0000; colorscreen : full_screen ABSOLUTE $b800:0000; Bad idea--this bombs if you compile in protected mode. full_screen_ptr = ^full_screen; Monoscreen : full_screen_ptr; colorscreen : full_screen_ptr; monoscreen := Ptr(SegB000, 0); colorscreen...

Borland has not released any patch for the runtime 200 problem in the CRT unit--support was long since dropped before it came to light (it takes a PII-200 or better to expose it). You'll have to get a third-party fix for it.

7.1 still has the CRT bug. It wasn't discovered until long after they quit dealing with the dos versions. Note that it's a lot easier to patch the offending code in the CRT unit than to replace the whole thing. I'm puzzled by why your original didn't work, though. Other than the upcase...

Nothing is handling the exception so it's still there--and thus the stack is unwound to the next handler.