Search results for query: *

may i join u guys :)? looks u managed the stack problem finally! the thing i want to comment is using 32 bit code in real mode. THIS IS POSSIBLE starting on 386+ CPUs. little example to make things clearer: suppose CPU is in real mode, 16-bit registers are native (but 32-bit accesible!). say...

as far as i know com port addresses are really the same all the time, and the data on their usage are stored in bios data area, i guess. but i'm a bit puzzled why a particular segment (0000 in this case is inaccesible? what platform is ur protected mode program? is it windows or a kind of PM mem...

i suppose this is an OS problem, and i feel it really intriguing. DoomMaster, can u give us a bit more info on ur proggy and errors it causes?

1st point - VB proggy does not seem a good target. older versions (i mean 3, 4) only loaded vbrunXX.dll and passed control to it for the purpose of interpertation of VB tokens. later versions, as far as i know, generate pseudocode for MS virtual machine and i wonder, if VB can generate a genuine...

concerning low/uppercase check in fact most hl functions just check bit 6 for this purpose. the idea is that uppercase chars are 41h-5Ah and lowercase are 61-7ah, so typical code sequence is like test al, 20h ;100000 binary jz uppercase so indeed there is no need for a special function...

not sure about XP but at least win9x accept parallel port IO for compatibility reasons. of course, this is not direct IO as windows manages port IO itself, but on application side it is transparent. i suppose parallel port addressing should work..

if u r not really meaning low-level parallel port programming (IO ports), u can rely on ur OS for the purpose: just open port as if it was a file using appropriate API and name LPT1 (LPT2 etc). not sure about windows but in dos u can send data to the PRN device also. regards, oleksii

notice to Ciralia very important is the SIZE of the stuff you put on the stack. in 32 bit intel CPUs you can put WORDs and DWORDs. probably it can be helpful if you consider DWORDs on the stack as an array of int addressed by the ESP register. btw, r u in 16 or 32-bit world? concerning ur...

just give us an idea what platform r u coding for?

Hi guys! u r right concerning jumps but this is applicable to 8086 instructions. as i can recall, for 386+ CPUs long conditional jumps are possible (at least for 32 bit code). here comes an example taken from some proggy in my windows dir: 0F8D09000000 jge 0004014FB...

to lionelhill. probably u'll code a crackme one day? :) the stuff u mentioned probably concerns jumps to a "misaligned" instruction - there is really such a antidebugging trick. concerning the prefetch queue - it's absolutely transparent on the coder side, the only thing one can bother...

no wonder - normally most inttrupts are redirected after boot. i presume u used a kind of debugger to have a look at IDT - it might well have happened that was the debugger who hooked INT 13. but if u trace the int handler code, u probably will find the reference to the original int handler...

defenitely we need a least the proc entrance/exit code to look at for making conclusions. little comment to lionehill - as far as i know any jump (in fact, any instruction changing IP) invalidates the prefetch queue. at least the things were this way for i486 regards

little summary. 1st, judging from ur code, u r trying to assembly a DOS com file. DOS int services ARE AVAILABLE under win9x. the original code itself looks OK, except for u should not set additional segment for data - com files are in ONE 16 bit SEGMENT. u can make a assembler to swallow this...

why do u need org 401000 directive? that's what makes ur exe so huge: 401000h = 4198400 decimal. looks u r confused with virtual address.. NO NEED to bother where ur code is to be loaded - this is up to windows loader, as i can recall. many win32 pragrams are loaded to THIS address (in fact...

remove org 100h directive and u will have ur code at cs:00. normally this address is used by the PSP structure, btw. regards

Hi ppl! i'm not sure code by AirCon will work - les bx, Sector will load some undetermined far pointer, is not that? - see the above lionelhill comment major point is that is it going to be an exe or com style program?? for com there is no need to bother about segments, as CS=DS=ES=SS at...

i'm with lionehill concerning (1). normally final executable has clear traces of hl compiler used - if you ever tried IDA u have a feeling what i mean. sure, such dissassemblers do not restore hl source, but normally one gets standard library references, some variables and structures determined...

why dont u just look with sice or ur other favorite debugger?

another option can be opening device PRN as a file and writing the string to it