IRC Networks
Irc Logs Stats
Start date: 2007-09-27 02:48:27
Last update: 2008-10-24 20:19:38
Channels: 41
Logged Lines: 6230436
Size: 1822.49 MB
Powered by
Channel Info
Network: freenodeChannel: #reactos |
Search in www.irclog.org
Log from #reactos at freenode 2006-06-29
Pages: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Next >
[00:00]<vrdfyg>GL: OK, read it.
[00:01]<afgw_ijggsau>!ntstatus 0xc00000034
[00:01]<vnaxbjv>Unable to find: c00000034
[00:01]<afgw_ijggsau>!ntstatus 0xc0000034
[00:01]<vnaxbjv>0xC0000034 is STATUS_OBJECT_NAME_NOT_FOUND
[00:01]<wynzm_w>Anyhow--- Maybe INT13 was a bad example--- How about the keyboard interrupt, or the mouse interrupt? How do the handlers (The programs referenced by the vector table) differ from the handlers provided by NTVDM? Do the handling programs get things done 'magiclly' in the 16bit world?
[00:01]<vrdfyg>wirds: Any defragmentation program (unless written by morons - or not using the rules) will work on any version of NT from NT4sp(3,4? I don't remember) up through at least XP (5.1).
[00:02]<wynzm_w>Tamlin-- Yes, this is because you arent supposed to 'brute force' the filesystem.
[00:02]<wynzm_w>But, there are special conditions you should take into account, with different FSes-- EG--- NTFS has the MFT reserved area.
[00:02]<vrdfyg>wierd: NTVDM handles this, just like e.g. DOSBox does.
[00:02]<vrdfyg>wierd: Yes, you need to know that stuff.
[00:03]<vrdfyg>You need to know a bit about e.g. NTFS to be able to write a "good" optimizer or defragmenter for it.
[00:03]<gznzvljzm>tamlin : freenode say u are unreg
[00:03]<wynzm_w>Tamlin, about NTVDM---- The handlers in a REAL dos box, do REAL things. The handlers provided by NTVDM would do 'magic'
[00:04]<vrdfyg>GL: Funny that I got a "+" when I identified myself then...
[00:04]<wynzm_w>Freenode is probably still having "Issues"
[00:04]<fyzn2rff>freenode often mistakes
[00:04]<gznzvljzm>prople
[00:05]<afgw_ijggsau>brb eat
[00:05]<gznzvljzm>tamlin : Did u agree with me what I did say about command.com
[00:05]<gznzvljzm>in swedish
[00:06]<vrdfyg>GreatLord: Not sure I did. You wrote it as seemingly in the context of NTVDM, so I'm not sure how to think of it.
[00:08]<wynzm_w>I could be (and probably am) wrong, but-- The way I think of NTVDM working, is that it has very minimal handler code in its 16 bit side. More than anything else, this code just raises flags in the 32bit side, so that the 32bit side can service the call, manipulate the 16 bit side, then pass "success".
[00:09]<wynzm_w>From inside 16bit world, where you cannot see 32bit world, requests would seem to just get handled out of thin air.
[00:09]<gznzvljzm>I am trying say command.com is a one file ms forget remove from windows 2000
[00:09]<vrdfyg>wierd: You're right.
[00:09]<vrdfyg>GreatLord: No, MS didn't forget to remove it. It was included on purpose.
[00:10]<gznzvljzm>for ntvdm is handling all intrupt and memmoery layout, and maping the memory, loading ntvdm drv
[00:10]<wynzm_w>Greatlord-- No, it services some of the needs of some REALLY cranky dos programs
[00:11]<gznzvljzm>myrira will write ntvdm to ros I think, she did talk about it
[00:11]<gznzvljzm>she want write it
[00:12]<emurgmcj>DOS VM? Cooool
[00:13]<vrdfyg>Sounds reasonably. I'm sure that fits her interests perfectly.
[00:13]<jyg>alright
[00:13]<jyg>now I'm getting somewhere
[00:13]<jyg>ROS will be on my laptop...soon :D
[00:13]<gznzvljzm>she have found some desgin fault in it
[00:13]<jyg>real hardware test
[00:13]<gznzvljzm>if u follow ms desgin
[00:13]<vrdfyg>Both CPU arhceology, and a potential for microoptimizations.
[00:14]<gznzvljzm>she told us it was easy to use it to gain access to most of the hardware
[00:14]<gznzvljzm>from user mode
[00:14]<vrdfyg>GL: I think I read about that too.
[00:14]<vrdfyg>Selectors, wasn't it?
[00:14]<gznzvljzm>I do not rember
[00:14]<gznzvljzm>she want redsign it
[00:15]<gznzvljzm>I think that is the reason ms did remove ntvdm from vista
[00:15]<gznzvljzm>I am thinking if we can not use dosbox some how
[00:16]<cjvyvy>Jin, It only takes about 3 minutes for me to install ReactOS
[00:16]<gznzvljzm>and if a dos program want run it start dosbox and run it in dosbox
[00:16]<gznzvljzm>wb Alex_Ionescu
[00:16]<afgw_ijggsau>thx
[00:16]<wynzm_w>Greatlord-- The problem, is that NTVDM is more than just for DOS applications.
[00:16]<wynzm_w>It is also for win16 applications, with help of WinOldApp
[00:17]<wd-afk>still talking about ntvdm and command.com
[00:17]<wynzm_w>Yes, but argument has gone more productive.
[00:17]<wd-afk>I somehow doubt that.
[00:17]<wynzm_w>Always so negative. :P
[00:17]<vrdfyg>GreatLord: No, there is a MUCH simpler reason MS removed NTVDM - it's simply not supported on any 64-bit CPU's (in 64-bit mode), as v86 mode isn't.
[00:18]<vrdfyg>GreatLord: What's needed there is something like QEMU. :-)
[00:18]<afgw_ijggsau>bullshit
[00:18]<afgw_ijggsau>VDM works perfectly on 64-bit cpus
[00:18]<vrdfyg>According to MS, YOUR statement is bullshit.
[00:18]<gznzvljzm>Alex_Ionescu what do u think why they remove it
[00:18]<wynzm_w>I would venture to say, it was more of a marketing decision---- Dos apps are what? 20+ years old?
[00:18]<wynzm_w>Why support it on a MODERN platform?
[00:18]<afgw_ijggsau>tamlin: go read the AMD x64 manuals and you’ll see that VDM is perfectly implementable
[00:19]<afgw_ijggsau>MS just didn’t want to bother with supporting
[00:19]<afgw_ijggsau>20-year old apps
[00:19]<wynzm_w>MS has been wanting to kill DOS for AGES
[00:19]<afgw_ijggsau>and had a great way out of it
[00:19]<vrdfyg>MS have explicitly stated "we do not support 16-bit apps on 64-bit CPUS (implicitly "in 64-bit mode").
[00:19]<afgw_ijggsau>by claiming “oh oops, 64-bit doesn’t work with it”
[00:19]<afgw_ijggsau>yeah that’s MS
[00:19]<afgw_ijggsau>that doesn’t mean the CPU doesn’t
[00:19]<usuzl>someone knows what is disk controller ACPI\PNP0700\1&7313ac9&0000 ?
[00:20]<gznzvljzm>Alex_Ionescu : I did speek about filip runing 16 and 32 bits code on windows 64bits
[00:20]<gznzvljzm>ms using so call long mode
[00:20]<gznzvljzm>in windows 64bits
[00:20]<afgw_ijggsau>yes
[00:20]<vrdfyg>Alex: So you mean both AMD and Intel 64-bit CPU's in 64-bit mode can and do support the 16-bit v86 mode?
[00:20]<afgw_ijggsau>tamlin: you can exit 64-bit mode, go to 32-bit mode, do your v86 stuff, and jump back
[00:20]<afgw_ijggsau>it’s documented.
[00:21]<gznzvljzm>that meaing only 64bits code can be run, so u need translate the memmory or do a simmluare to a context switch
[00:21]<afgw_ijggsau>(a PITA to do, but don’t tell MS suddently lost all their low-level CPU coders)
[00:21]<afgw_ijggsau>tell me*
[00:21]<vrdfyg>Usurp: That makes no sense to me. Vendor ID is 16 bits. "7313ac9" is 28 bits.
[00:22]<gznzvljzm>Alex_Ionescu : if ms did use short mode it should handling 16/32/64 bits code without any problem
[00:22]<wynzm_w>Failing that, you could just simulate v86 mode in software, and say "screw speed"
[00:22]<afgw_ijggsau>GreatLord: you can exit long mode.
[00:22]<gznzvljzm>yes that is expnesive
[00:22]<gznzvljzm>when everthing is runing in long mode
[00:22]<afgw_ijggsau>it’s a 1980 app
[00:22]<usuzl>tamlin: thats what reported when enabling acpi into reactos output
[00:22]<afgw_ijggsau>it’s probably going to run too fast anyway
[00:23]<afgw_ijggsau>who cares if it’s going to be 0.0005 microsec longer
[00:23]<vrdfyg>Alex: Heads up!
[00:24]<afgw_ijggsau>?
[00:24]<gznzvljzm>why did ms choice to trunking the 32bits apps with wow64
[00:24]<gznzvljzm>why did ms choice to trunking the 32bits apps with wow32







