Ros-dev

ros-dev@reactos.org

5788 discussions

by Steven Edwards

--- Phillip Susi <psusi(a)cfl.rr.com> wrote: > Steven Edwards wrote: > > We have PSEH which can be used. > > > > Thanks > > Steven > > PSEH? We have a macro based SEH implementation we are using in ReactOS called PSEH for Portable SEH. Hyperion wrote it and it seems to work with almost ever compiler thrown at it. It is not syntax compatible with MS-SEH but some people have been working to develop p(retty)pseh which should be. Look in reactos/lib/pseh and grep the source tree. Its used in ntoskrnl, win32k, afd?, and others. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

19 years, 5 months

Re: [ros-dev] Error handling

by \(\) Thomas Larsen \(\)

NTSTATUS DoSomething() { NSTATUS Status; ... Status = NtXXX(); if (!NT_SUCCESS(Status)) goto done; Status = NtYYY(); if (!NT_SUCCESS(Status)) goto cleanXXX; Status = NtZZZ(); if (!NT_SUCCESS(Status)) goto cleanYYY; cleanZZZ: cleanupZZZ(); cleanYYY: cleanupYYY(); cleanXXX: cleanupXXX(); done: return Status; }Thomas NTSTATUS DoSomething() { NSTATUS Status = NtXXX(); if (NT_SUCCESS(Status)) { Status = NtYYY(); if (!NT_SUCCESS(Status)) cleanupXXX(); Status = NtZZZ(); if (!NT_SUCCESS(Status)) cleanupYYY(); } return Status; } i think thats the most simple and easy to read but in the end is´ent it not a littel waste of time discusse old functions their need rewrite anyway..? Thomas

19 years, 5 months

Re: [ros-dev] Error handling

by Steven Edwards

Hi, --- Phillip Susi <psusi(a)cfl.rr.com> wrote: > How is it not readable? I think it is MUCH better than the original > code. You don't have a half dozen lines of (mostly duplicated) cleanup > code after every call, but what you're calling and what you're passing > to it are still quite clear. Like I said though, it still isn't as > ideal as SEH, but it's not the terrible mess the original code was. If > you have any suggestions on how to make it even more clean, I'm all ears. We have PSEH which can be used. Thanks Steven __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

19 years, 5 months

floppy.sys problem

by Hartmut Birr

Hi, with my last changes it is possible to install ros from the boot cd and select the floppy as boot device. Currently there exist three problems. After selecting the floppy as boot medium it is shown a dialog box which does mean, there is no disk inserted. A second try detect the disk. The installer copies all files to the floppy disk. After trying to restart the computer, ros hangs. I must manually reset the pc. The floppy disk is still inserted at this point. The pc does boot up, accessing the floppy disk, shows 'Loading FreeLoader...' and shows 'Disk error \nPress any key". Pressing a key results in the same message. If I remove and insert the disk again, I can load freeloader from the floppy disk and it does boot reactos. It seems, that the bios isn't able to initialize the floppy controller correctly after reactos was running. I've added a shutdown procedure in floppy.sys which resets the floppy controller over the DSR register, but this doesn't help. Has anyone an idea what is wrong? - Hartmut

19 years, 5 months

Freeldr problems resolved

by Phillip Susi

Well, I finally solved my problems with getting freeldr to boot from a hard drive. The first is a problem with fat.bin itself. Early during it's execution it checks to see if the boot sector header specifies a device ID of 0xff, and if so, it uses the device ID the bios passes in CL when it invokes the boot sector, otherwise it uses the device ID in the boot sector header. The device ID field of the boot sector is inherently unreliable and should NEVER be used. In my case mtools was leaving it as it was in fat.bin, which is 0, so it was trying to access the floppy instead of the hard disk. I have fixed this by removing the check to see if the field is 0xff, so the code will always use the device passed by the bios. The second problem was far more stupid. mtools was not specifying O_BINARY when opening the boot sector template file, and as a result, cygwin was translating newlines, so it clobbered the boot sector. I'm all set to check in the fix to fat.asm, but I was never asked by subversion ( tortoise client ) to log in, so I assume it just used anon or something. How do I tell subversion to log me in as me?

19 years, 5 months

ros 0.2.6 is up

by Robert Köpferl

So, hope next time this will be 0.3

19 years, 5 months

Re: [ros-dev] Freeldr problems resolved

by Sylvain Petreolle

A simpler fix would be to a change of the BootDrive value to 0xFF. As you said, the current value is 0, but thats by design, since all the values have been filled for a 1.44M diskette. Even the File System ID could have been set differently, since the neutral value 'FAT ' is allowed here. --- Phillip Susi <psusi(a)cfl.rr.com> wrote: > Well, I finally solved my problems with getting freeldr to boot from a > hard drive. The first is a problem with fat.bin itself. Early during > it's execution it checks to see if the boot sector header specifies a > device ID of 0xff, and if so, it uses the device ID the bios passes in > CL when it invokes the boot sector, otherwise it uses the device ID in > the boot sector header. The device ID field of the boot sector is > inherently unreliable and should NEVER be used. In my case mtools was > leaving it as it was in fat.bin, which is 0, so it was trying to access > the floppy instead of the hard disk. I have fixed this by removing the > check to see if the field is 0xff, so the code will always use the > device passed by the bios. Kind regards, Usurp (aka Sylvain Petreolle) humans are like computers, yesterday the BIOS was all - today its just a word

19 years, 5 months

RE:[ros-diffs] [fireball] 14571: Fix incorrect file name of kgbgb.dllto kbduk.dll (by unC0Rr), added kbdru.dll into keyboard layouts

by Casper Hornstrup

Oops? Fix incorrect file name of kgbgb.dll to kbduk.dll (by unC0Rr), added kbdru.dll into keyboard layouts Modified: trunk/reactos/bootdata/txtsetup.sif ________________________________________ Modified: trunk/reactos/bootdata/txtsetup.sif --- trunk/reactos/bootdata/txtsetup.sif 2005-04-10 11:18:05 UTC (rev 14570) +++ trunk/reactos/bootdata/txtsetup.sif 2005-04-10 11:35:19 UTC (rev 14571) @@ -34,8 +34,8 @@ [SetupData] DefaultPath = \ReactOS -OsLoadOptions = "/NOGUIBOOT /NODEBUG" -;OsLoadOptions = "/NOGUIBOOT /DEBUGPORT=COM1" +;OsLoadOptions = "/NOGUIBOOT /NODEBUG" +OsLoadOptions = "/NOGUIBOOT /DEBUGPORT=COM1 /BAUDRATE=19200 /IRQ=4" ;OsLoadOptions = "/NOGUIBOOT /DEBUGPORT=SCREEN" ;OsLoadOptions = "/NOGUIBOOT /DEBUGPORT=BOCHS"

19 years, 5 months

Re: [ros-svn] [phreak] 14567: Fixed freeldr fat16 boot sector to use the bios provided boot device number instead of the ( usually invalid ) one in the boot sector header.

by Thomas Weidenmueller

phreak(a)svn.reactos.com wrote: >Fixed freeldr fat16 boot sector to use the bios provided boot device number instead of the ( usually invalid ) one in the boot sector header. > > Could you please fix that also in the fat32 bootsector? Best Regards, Thomas

19 years, 5 months

KeBugCheck

by James Tabor

Hi! This is svn build 14542, (NTDLL:ldr/utils.c:2097) Relocating (77ed0000 -> 780000) C:\ReactOS\System32\gdi 32.dll (KERNEL32:mem/global.c:412) Memory Load: 23 (KERNEL32:mem/global.c:412) Memory Load: 23 (KERNEL32:mem/global.c:412) Memory Load: 23 (KERNEL32:mem/global.c:412) Memory Load: 23 (MSVCRT:io/open.c:103) not valid fd 0, g_fdend 5, fdinfo 7802d2f0, bucket 7802d2 f0, fdflags 0 (MSVCRT:io/open.c:700) _setmode: inval fd (0) (NTDLL:ldr/utils.c:2097) Relocating (77ed0000 -> 780000) C:\ReactOS\System32\gdi 32.dll ex/handle.c:909: Pagable code called at IRQL > APC_LEVEL (0) KeBugCheck at ex/handle.c:909 A problem has been detected and ReactOS has been shut down to prevent damage to your computer. The bug code is undefined. Please use an existing code instead. Technical information: *** STOP: 0x00000000 (0x00000000,0x00000000,0x00000000,0x00000000) Frames: <ntoskrnl.exe:dbe3 (ke/bug.c:459 (KeBugCheckEx))> <ntoskrnl.exe:dc03 (ke/bug.c:479 (KeBugCheck))> <ntoskrnl.exe:3dcee (ex/handle.c:909 (ExMapHandleToPointer))> <ntoskrnl.exe:92b23 (ob/handle.c:768 (ObReferenceObjectByHandle))> <ntoskrnl.exe:3b3f2 (ex/event.c:476 (NtSetEvent))> <ntoskrnl.exe:3c22 (/tmp/ccAGlOXR.s:178 (KiSystemService))> <ntdll.dll:a414 (rtl/critical.c:502 (RtlpUnWaitCriticalSection))> Entered debugger on embedded INT3 at 0x0008:0x800064be. kdb:> No keyboard, James

19 years, 5 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev