Page 5 of 9
Re: bewing's complete bochs rewrite: test request
Posted: Sun May 30, 2010 4:28 am
by Owen
Just a tip to speed up Qt: after creating your QApplication, call 'app.setRenderSystem("raster");'. Raster is significantly faster than the default X11 render system (Its also the default on Windows; I don't know how it compares with GDI for speed)
I presume x11 is kept as the default for backwards compatibility.
Re: bewing's complete bochs rewrite: test request
Posted: Sun May 30, 2010 6:33 am
by bewing
@Creature: Even 20 years later,
16 bit apps are still supported on Windoze. It'll be decades before 32bit becomes unusably obsolete. In that time, I expect that GTK and Qt will have morphed to the point where I have to rewrite my toolkits to support the current versions. The one thing I think I can guarantee is that my win32 code will still run perfectly -- because nobody is fscking around with that standard anymore. It may not be state of the art, but stability is a wonderful thing.
@Owen: Thanks! That's exactly the sort of tip that is extremely helpful.
Re: bewing's complete bochs rewrite: test request
Posted: Sun May 30, 2010 6:42 am
by WindowsNT
16-bit apps are partially supported (not in x64) because simply it costs nothing to remove the support. How many 16-bit applications (except old games which are run through emulator) are there ? None.
But of course, as I said earlier. When Windows is finally released in x64 only, then programmers will start more programming in x64. And when Windows finally removes support for x86 (here it doesn't cost "nothing"), then x86 vanishes.
You should not parallelize 16-bit with 32-bit, because 16- bit could only have a few MBs usage; 32-bit can have up to 4GB which is almost enough for anyone (and will be enough for most even if years pass). But it isn't a policy of what I need or what you need; It's a marketing policy.
Re: bewing's complete bochs rewrite: test request
Posted: Sun May 30, 2010 6:45 am
by Owen
Qt breaks backwards compatibility every few years; last time this happened was 2005 and its not expected to occur again any time in the near future, as Qt4 is still a very good platform to develop applications on. The Trolls know just how valuable full backwards compatibility (That is both API and ABI compatibility) is to their customers.
But yes, they will eventually release Qt5. However, you can expect that almost everything removed and replaced will be kept available somehow. For example, for porting Qt3 apps to Qt4 the Qt3Support library exists. This includes most of the classes from Qt3 which were removed, renamed from QSomething to Q3Something. Additionally, defining the correct preprocessor symbol will make Qt4 expose most of the class methods from Qt3 which were removed. It would be reasonable to expect that Qt5 would include a Qt4Support library.
This legacy support will be kept in for the lifetime of Qt4, though it is at this point unsupported (i.e. no bug fixes will occur, only fixes for security issues). Since Qt4 has been out for 5 years, and it should not be being written into new code and therefore no new bugs should be exposed, this is rather reasonable.
WindowsNT wrote:16-bit apps are partially supported (not in x64) because simply it costs nothing to remove the support. How many 16-bit applications (except old games which are run through emulator) are there ? None.
But of course, as I said earlier. When Windows is finally released in x64 only, then programmers will start more programming in x64. And when Windows finally removes support for x86 (here it doesn't cost "nothing"), then x86 vanishes.
You should not parallelize 16-bit with 32-bit, because 16- bit could only have a few MBs usage; 32-bit can have up to 4GB which is almost enough for anyone (and will be enough for most even if years pass). But it isn't a policy of what I need or what you need; It's a marketing policy.
Lots. Microsoft have customers who depend upon 16-bit apps and have no intention of migrating off of them. 16-bit support is kept around and bugfixed because it sells copies.
Re: bewing's complete bochs rewrite: test request
Posted: Sun May 30, 2010 9:41 am
by Creature
I don't see why they didn't release Windows 7 as 64-bit only. Processors of the last 5 or 6 years support 64-bit (even around Windows XP, when almost everybody still used 32-bit). So processors that actually need a 32-bit version of Windows 7 (and don't support 64-bit), IMO are so old they shouldn't be running Windows 7 in the first place. You could still run 32-bit on 64-bit . If backwards compatibility is so important (and it is for Microsoft), why don't they just throw out all the backwards compatibility code and write a virtualization layer instead (like Apple did)? People who don't want the backwards compatibility won't be slown down because of it and people who do want it can use it if they like.
Re: bewing's complete bochs rewrite: test request
Posted: Mon May 31, 2010 4:58 am
by Owen
Creature wrote:I don't see why they didn't release Windows 7 as 64-bit only. Processors of the last 5 or 6 years support 64-bit (even around Windows XP, when almost everybody still used 32-bit). So processors that actually need a 32-bit version of Windows 7 (and don't support 64-bit), IMO are so old they shouldn't be running Windows 7 in the first place. You could still run 32-bit on 64-bit . If backwards compatibility is so important (and it is for Microsoft), why don't they just throw out all the backwards compatibility code and write a virtualization layer instead (like Apple did)? People who don't want the backwards compatibility won't be slown down because of it and people who do want it can use it if they like.
An Intel Atom is old now?
As for the backwards compatibility thing: Why do you think they included the XP virtual machine?
Re: bewing's complete bochs rewrite: test request
Posted: Mon May 31, 2010 9:13 am
by Creature
Owen wrote:Creature wrote:I don't see why they didn't release Windows 7 as 64-bit only. Processors of the last 5 or 6 years support 64-bit (even around Windows XP, when almost everybody still used 32-bit). So processors that actually need a 32-bit version of Windows 7 (and don't support 64-bit), IMO are so old they shouldn't be running Windows 7 in the first place. You could still run 32-bit on 64-bit . If backwards compatibility is so important (and it is for Microsoft), why don't they just throw out all the backwards compatibility code and write a virtualization layer instead (like Apple did)? People who don't want the backwards compatibility won't be slown down because of it and people who do want it can use it if they like.
An Intel Atom is old now?
As for the backwards compatibility thing: Why do you think they included the XP virtual machine?
Point taken on the Intel Atom. But the Windows XP Virtual machine can hardly be called "a virtualization layer": it permanently hogs a portion of your memory, uses MS' crappy VirtualPC (which STILL doesn't have 3D support or any of the likes, so no decent gaming etc (not saying that I want to use it, but some people might and thus it should be considered, the same principle as goes for old applications)) and I doubt MS has removed a lot of the backwards compatibility code in Windows 7 up until now. Still, they are on the right track. Using e.g. VirtualBox instead of VirtualPC would perhaps be a better solution, if MS wouldn't be so kind to restrict the Windows XP license only to VirtualPC. Also people having more basic variants of Windows 7 aren't so fortunate to have access to Windows XP Mode (which brings us to the discussion if so many versions are necessary, but that's besides the point).
Re: bewing's complete bochs rewrite: test request
Posted: Tue Jun 01, 2010 3:38 pm
by Gigasoft
WindowsNT wrote:How many 16-bit applications (except old games which are run through emulator) are there ? None.
I still compose on good old Magix Music Studio 3.0, which I have used since I had Windows 3.11.
Re: bewing's complete bochs rewrite: test request
Posted: Mon Aug 09, 2010 1:56 am
by Artlav
It's been quiet lately, how's the project going?
One thing on a wishlist - let it not just say that something went wrong (ldmxcsr, exception, exception, exception, 3rd exception with no resolution), but what exactly went wrong (ldmxcsr, cr4.osfxsr=0 -> #UD).
Re: bewing's complete bochs rewrite: test request
Posted: Wed Aug 11, 2010 6:35 am
by bewing
With the current version, GRUB should work AFAIK. If anyone has a floppy image for GRUB that does not load an OS successfully, I would really like to see that image.
The next things that I know of that are keeping most OSes from running are some kind of error in initializing paging, and some kind of SDL keyboard input bug. I will be fixing the paging error very soon.
@Artlav: thanks for the suggestion. For anything that seems like a bug in an OS, I try to display a message in the logfile.
Re: bewing's complete bochs rewrite: test request
Posted: Wed Aug 11, 2010 7:36 am
by Artlav
bewing wrote:With the current version, GRUB should work AFAIK. If anyone has a floppy image for GRUB that does not load an OS successfully, I would really like to see that image.
The next things that I know of that are keeping most OSes from running are some kind of error in initializing paging, and some kind of SDL keyboard input bug. I will be fixing the paging error very soon.
EDIT: Testing on source package which seems to correspond to revision 38.
GRUB works Ok, but what follows it is kinda sketchy.
-REP prefix won't work properly if ecx=0. Putting the if block at line 586 in cpu.c (do_inst_reps) under "if(cxval!=0xFFFFFFFF){" seems to fix it, as the value is pre-decremented but not checked, resulting in 4b32 repeats.
-I haven't found a way to easily define a breakpoint at given address, shortest way is disassemble->address->breakpoint
-Sometimes the disassembly is misaligned with execution point, putting it off-screen (win32)
-There are loads of "000000000000b454e[MEMORY] (Err#01) very inefficient misaligned memory access to linear address 0000000000000463, size 2" kinds of errors, i suspect obscuring all others.
-An option to have classic port e9 would be nice, as well as IO port-induced breakpoint. Both are very handy tools.
After all that it gives illegal opcode exception to fnsave ds:[ebx] (DD 33), on which i concluded my test for lack of a way to continue.
Hope this helps.
Re: bewing's complete bochs rewrite: test request
Posted: Wed Aug 11, 2010 11:15 am
by Artlav
Another problem found - if there is a hlt instruction and CPU waits for an interrupt something don't quite work out.
Example: int 16h, ah=0, keypresses go into the buffer, interrupt seems signalled, but the CPU keeps looping in do_cpuloops.
After first key press the loop changes slightly, "if (*stopcode < 0)" (cpu.c:956) no longer trigger, but it never quits to next instruction.
Could that be related to "SDL keyboard input bug"?
Re: bewing's complete bochs rewrite: test request
Posted: Wed Aug 11, 2010 12:25 pm
by bewing
Artlav wrote:
GRUB works Ok, but what follows it is kinda sketchy.
Heh. This is alpha test software. Of course it's sketchy.
-REP prefix won't work properly if ecx=0. Putting the if block at line 586 in cpu.c (do_inst_reps) under "if(cxval!=0xFFFFFFFF){" seems to fix it, as the value is pre-decremented but not checked, resulting in 4b32 repeats.
Could you please explain a little more what you mean? If you do a REP and ECX is 0, it should repeat 4 billion times.
-I haven't found a way to easily define a breakpoint at given address, shortest way is disassemble->address->breakpoint
Actually, if you just type "b 0x????" it will set a breakpoint there. It does not give visual feedback at the moment. But the disassemble / doubleclick also works, as you say.
-Sometimes the disassembly is misaligned with execution point, putting it off-screen (win32)
Yes, there is no possible way of avoiding this. The code waits one instruction to see if the disassembly becomes realigned, before doing a refresh. If you want the refresh immediately, hit the refresh button.
-There are loads of "000000000000b454e[MEMORY] (Err#01) very inefficient misaligned memory access to linear address 0000000000000463, size 2" kinds of errors, i suspect obscuring all others.
This is a result of very bad programming in grub, using many misaligned memory accesses. No, it does not obscure any other errors.
-An option to have classic port e9 would be nice, as well as IO port-induced breakpoint. Both are very handy tools.
Could you explain a little more? I support port 0xe9 -- but it is slightly different from bochs e9 support, because the way bochs uses the port is stupid. What IO port induced breakpoint is this? I've never used it.
Another problem found - if there is a hlt instruction and CPU waits for an interrupt something don't quite work out. ...
After first key press the loop changes slightly, "if (*stopcode < 0)" (cpu.c:956) no longer trigger, but it never quits to next instruction.
That's very interesting. I will look into that.
Hope this helps.
Yes, it was helpful. Thanks!
Re: bewing's complete bochs rewrite: test request
Posted: Wed Aug 11, 2010 12:45 pm
by Artlav
bewing wrote:Could you please explain a little more what you mean? If you do a REP and ECX is 0, it should repeat 4 billion times.
It should?
I couldn't find a mention in the Intel docs.
Thing in question:
mov ecx,0
rep stosb
Why i think doing nothing is the right thing:
-Otherwise rebochs hangs solid, so there is a problem around there somewhere
-Bochs does nothing
-It's more consistent to do nothing
I can add to that that i just tried it on the actual PC and the result is - do nothing.
Unless i missed some other meaning?
bewing wrote:
-An option to have classic port e9 would be nice, as well as IO port-induced breakpoint. Both are very handy tools.
Could you explain a little more? I support port 0xe9 -- but it is slightly different from bochs e9 support, because the way bochs uses the port is stupid. What IO port induced breakpoint is this? I've never used it.
Not quite stupid - it's a quick and easy way to write out debug information, in two commands you can send a mark into the console that something went wrong or right. It's like a serial port.
By breakpoint i meant this sequence:
Code: Select all
mov dx,8A00h
mov ax,dx
out dx,ax
mov ax,8AE0h
out dx,ax
Which in Bochs breaks execution and gives you debug prompt.
Very handy.
Re: bewing's complete bochs rewrite: test request
Posted: Wed Aug 11, 2010 12:54 pm
by Owen
AMD says that "Repetition is terminated when rCX reaches zero", which implies to me that it is terminated if rCX is zero *after* the decrement. In fact, if Bochs is not doing the repetition in that case, it is very, very buggy and will choke randomly on a lot of optimized code, because "rep ret" is a very common optimization
(Why is "rep ret" used? If your ret is a branch target, then K8s will utterly fail to predict it; AMD's recommended optimization is to prefix the ret with a rep. This obviously also implies that branches should disable the repetition)