My english is sometimes poor
For the first i give a shit public or not
1. One day i found reactos 2. Where looking on how you made reactos drivers and got (exiting=happy dont know how to spell) 3. Got Ida Disam in demo version 4. Disam shell32 and scsiport.sys Theire where lot of places where it where identical 5. Microsoft Source leak my friend just downloaded it i got parts of the code what could be on my 1,33 mb floppy 6. Saw scsiport.sys where 90% identical i layout and code and alittel of shell32 7. Wrote one mail or two dont remember saying it should newer have done so 8. Got many really unhappy ppl. email answers (they want to see the source and No i dident) 9. Talked with alot of ppl and i discover that i where not right 10. Worked on with reactos 11. The mail today
;I'm not quite sure what you're driving at, but are you saying you ;posess(ed) the leaked sources? And - by comparing it with ReactOS/WINE - ;we must have been tainted with it? I really hope I mistook that.
i dident possess (in my word book its is "showing" the source) And no that where not what i meant to say
Im Saying that i could just have changed email and name (NO Worry i dident do that)
And my point only where give me a chance the only thing i want to is to help reactos.. but it seems that their are no chance so saying goodbye.. sry..
Thomas
__________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
Thomas Larsen schrieb:
- Disam shell32 and scsiport.sys Theire where lot of places where it where identical
The M$ compiler and gcc is very different. If you compare the assembler code which is compiled from the same source, you can found the same functions bodies, but inside the functions there are many differences. Some time ago, I've ported a simple driver for an eprom programer from M$ tools to the ReactOS build system. At the start it hasn't worked, because I forgot the stdcall attributes for some functions. The reassembled code was very different.
- Microsoft Source leak my friend just downloaded it i got parts of the code what could be on my
1,33 mb floppy
If you was interessted to compare the ros and M$ code, you have never worked with a floppy. It is too simple to burn a cd or dvd.
- Saw scsiport.sys where 90% identical i layout and code and alittel of shell32
Some parts of scsiport are from me. I've never seen the scsiport sources from M$. I'm not sure which code from M$ you know. Our scsiport is more compatible with the NT4.0 one. I've test many scsi controller with its NT 4.0 drivers (adaptect 2940, ataptec on asus p2d, dmx3194uw, diamond fireport, tekram dc390, initio a100, some with different lsi chipset, some with initio 950 chip set). I think M$ has lost the W2K sourcesand not the NT4.0 one. Our scsiport is very different from W2k and it is different from NT4.0. I've add a list of imported functions. Some functions are very specific for the implemention. ReactOS doesn't use IoFreeMdl, IoFreeIrp, the DeviceQueu functions and some others. Many things may nearly the same, bcause they must implement the some functions. Our implementation is different from M$. The different imported functions shows this. You cannot find 90% identical, if you compare our source with the M$ source.
- Hartmut
ReactOS NT4.0 W2K
_allmul x _aullshr x _except_handler3 x _strnicmp x x x _wcsnicmp x x DbgBreakPoint x x DbgPrint x x ExAllocatePool x ExAllocatePoolWithTag x x x ExDeleteNPagedLookasideList x ExFreePool x x x ExInitializeNPagedLookasideList x ExInterlockedPopEntrySList x ExInterlockedPushEntrySList x InterlockedCompareExchange x InterlockedDecrement x x x InterlockedExchange x x InterlockedExchangeAdd x InterlockedIncrement x x IoAllocateAdapterChannel x x IoAllocateDriverObjectExtension x IoAllocateErrorLogEntry x x IoAllocateIrp x IoAllocateMdl x IoAllocateWorkItem x IoAssignResources x IoAttachDeviceToDeviceStack x IoBuildAsynchronousFsdRequest x x IoBuildDeviceIoControlRequest x x IoBuildSynchronousFsdRequest x x IoCallDriver x IoCompleteRequest x IoConnectInterrupt x x x IoCreateDevice x x x IoCreateSymbolicLink x x x IoDeleteDevice x x x IoDeleteSymbolicLink x IoDetachDevice x IoDisconnectInterrupt x x x IofCallDriver x x IofCompleteRequest x x IoFreeIrp x x IoFreeMdl x x IoFreeWorkItem x IoGetConfigurationInformation x x x IoGetDeviceProperty x IoGetDriverObjectExtension x IoInitializeIrp x IoInitializeTimer x x x IoInvalidateDeviceRelations x IoInvalidateDeviceState x IoOpenDeviceRegistryKey x IoQueryDeviceDescription x x IoQueueWorkItem x x IoRegisterDeviceInterface x x IoReportDetectedDevice x x IoInvalidateDeviceRelations x IoInvalidateDeviceState x IoOpenDeviceRegistryKey x x IoQueryDeviceDescription x x IoQueueWorkItem x x IoRegisterDeviceInterface x x IoReportDetectedDevice x x IoWriteErrorLogEntry x x KeAcquireSpinLockAtDpcLevel x x KeBugCheck x KeBugCheckEx x KeCancelTimer x KefAcquireSpinLockAtDpcLevel x x KefReleaseSpinLockFromDpcLevel x x KeInitializeDeviceQueue x x KeInitializeDpc x x x KeInitializeEvent x x x KeInitializeSpinLock x x x KeInitializeTimer x x KeInsertByKeyDeviceQueue x x KeInsertDeviceQueue x KeInsertQueueDpc x x x KeReadStateEvent x x KeReleaseSpinLockFromDpcLevel x x KeRemoveDeviceQueue x KeRemoveByKeyDeviceQueue x KeRemoveDeviceQueue x KeResetEvent x KeSetEvent x KeSetTimer x x KeSynchronizeExecution x x x KeWaitForMultipleObjects x KeWaitForSingleObject x x memcpy x Mm64BitPhysicalAddress x MmAllocateContiguousMemorySpecifyCache x MmBuildMdlForNonPagedPool x MmFreeContiguousMemorySpecifyCache x MmGetPhysicalAddress x x MmHighestUserAddress x MmLockPagableDataSection x MmMapIoSpace x x x MmUnlockPagableImageSection x MmUnmapIoSpace x x x NlsMbCodePageTag x ObfDereferenceObject x x ObfReferenceObject x x ObReferenceObjectByHandle x ObReferenceObjectByPointer x PoCallDriver x PoRegisterDeviceForIdleDetection x PoRequestPowerIrp x PoSetPowerState x PoStartNextPowerIrp x RtlAnsiStringToUnicodeString x x RtlAppendUnicodeStringToString x x RtlAreBitsSet x RtlAssert x RtlClearAllBits x x RtlClearBits x x RtlCompareMemory x RtlCopyUnicodeString x x RtlFindClearBitsAndSet x x RtlFreeUnicodeString x x RtlInitAnsiString x x RtlInitializeBitMap x x RtlInitUnicodeString x x x RtlIntegerToUnicodeString x x RtlMoveMemory x RtlZeroMemory x RtlQueryRegistryValues x RtlSetBits x RtlStringFromGUID x RtlUnicodeStringToAnsiString x x RtlUnicodeStringToInteger x RtlxAnsiStringToUnicodeSize x RtlUnwind x sprintf x x x swprintf x x vsprintf x wcslen x x x wcsrchr x ZwClose x x x ZwCreateDirectoryObject x ZwCreateKey x x x ZwDeleteKey x ZwEnumerateValueKey x x ZwOpenKey x x ZwQueryValueKey x x ZwSetValueKey x x x
No
Microsoft lost big parts of the Source Code of Windows 200 & NT 4.0 (more NT 4 then 200). But it's not enough source code to compile your own Windows!
pentiumforever
-----Ursprüngliche Nachricht----- Von: ros-dev-bounces@reactos.com [mailto:ros-dev-bounces@reactos.com] Im Auftrag von Hartmut Birr Gesendet: Freitag, 11. März 2005 17:54 An: ReactOS Development List Betreff: Re: [ros-dev] Saying To All
Thomas Larsen schrieb:
- Disam shell32 and scsiport.sys Theire where lot of places where it where
identical
The M$ compiler and gcc is very different. If you compare the assembler code which is compiled from the same source, you can found the same functions bodies, but inside the functions there are many differences. Some time ago, I've ported a simple driver for an eprom programer from M$ tools to the ReactOS build system. At the start it hasn't worked, because I forgot the stdcall attributes for some functions. The reassembled code was very different.
- Microsoft Source leak my friend just downloaded it i got parts of the
code what could be on my
1,33 mb floppy
If you was interessted to compare the ros and M$ code, you have never worked with a floppy. It is too simple to burn a cd or dvd.
- Saw scsiport.sys where 90% identical i layout and code and alittel of
shell32
Some parts of scsiport are from me. I've never seen the scsiport sources from M$. I'm not sure which code from M$ you know. Our scsiport is more compatible with the NT4.0 one. I've test many scsi controller with its NT 4.0 drivers (adaptect 2940, ataptec on asus p2d, dmx3194uw, diamond fireport, tekram dc390, initio a100, some with different lsi chipset, some with initio 950 chip set). I think M$ has lost the W2K sourcesand not the NT4.0 one. Our scsiport is very different from W2k and it is different from NT4.0. I've add a list of imported functions. Some functions are very specific for the implemention. ReactOS doesn't use IoFreeMdl, IoFreeIrp, the DeviceQueu functions and some others. Many things may nearly the same, bcause they must implement the some functions. Our implementation is different from M$. The different imported functions shows this. You cannot find 90% identical, if you compare our source with the M$ source.
- Hartmut
From what I made out from all the hooha over the leaked source code, it was
about the same size (in MB) of NT 4.0 and Win2k. NT 4.0 is significantly smaller than Win2k - I've installed both for a course I did in A+ - though it's nowhere near as small as NT 3.1.
Consequently, a lot more NT 4.0 source code got leaked than did Win2k. (I've never seen it - and I don't want to, unless I've got a declaration from Microsoft that the NT source code (3.1 to 5.1) is now available under an acceptable Open Source license - preferrably 3-clause BSDL, since they appear to like that! ;-) I won't even look at MS Academic Shared Source source code at University, because MS are that paranoid, and are willing to throw "mental contamination" theories around like a pyromaniac with a flamethrower.
Reverse engineering's a different story, because Microsoft Press has published "Inside Windows NT", several editions including the Win2k one, and I kid you not, they give detailed instructions on reverse-engineering NT. "Tools for Digging into Windows NT Internals" - that ring a bell? i386kd, windbg, apimon, gflags, pwalk, pfmon, I could go on ... David A. Solomon goes into detail.
But as I understand it, ReactOS is an NT-class/style/type kernel (much in the way NT itself is a VMS-class kernel with a Win32 userland.) with a Wine-based userland, and reverse-engineering wasn't involved in either developing the kernel or in developing the Win32 userland.
I'm getting sick of these people with unsupported allegations.
Wesley Parish
On Sat, 12 Mar 2005 06:18, Rouven Weßling wrote:
No
Microsoft lost big parts of the Source Code of Windows 200 & NT 4.0 (more NT 4 then 200). But it's not enough source code to compile your own Windows!
pentiumforever
-----Ursprüngliche Nachricht----- Von: ros-dev-bounces@reactos.com [mailto:ros-dev-bounces@reactos.com] Im Auftrag von Hartmut Birr Gesendet: Freitag, 11. März 2005 17:54 An: ReactOS Development List Betreff: Re: [ros-dev] Saying To All
Thomas Larsen schrieb:
- Disam shell32 and scsiport.sys Theire where lot of places where it
where
identical
The M$ compiler and gcc is very different. If you compare the assembler code which is compiled from the same source, you can found the same functions bodies, but inside the functions there are many differences. Some time ago, I've ported a simple driver for an eprom programer from M$ tools to the ReactOS build system. At the start it hasn't worked, because I forgot the stdcall attributes for some functions. The reassembled code was very different.
- Microsoft Source leak my friend just downloaded it i got parts of the
code what could be on my
1,33 mb floppy
If you was interessted to compare the ros and M$ code, you have never worked with a floppy. It is too simple to burn a cd or dvd.
- Saw scsiport.sys where 90% identical i layout and code and alittel of
shell32
Some parts of scsiport are from me. I've never seen the scsiport sources from M$. I'm not sure which code from M$ you know. Our scsiport is more compatible with the NT4.0 one. I've test many scsi controller with its NT 4.0 drivers (adaptect 2940, ataptec on asus p2d, dmx3194uw, diamond fireport, tekram dc390, initio a100, some with different lsi chipset, some with initio 950 chip set). I think M$ has lost the W2K sourcesand not the NT4.0 one. Our scsiport is very different from W2k and it is different from NT4.0. I've add a list of imported functions. Some functions are very specific for the implemention. ReactOS doesn't use IoFreeMdl, IoFreeIrp, the DeviceQueu functions and some others. Many things may nearly the same, bcause they must implement the some functions. Our implementation is different from M$. The different imported functions shows this. You cannot find 90% identical, if you compare our source with the M$ source.
- Hartmut
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
-
Hartmut Birr -
Rouven Weßling -
Thomas Larsen -
Wesley Parish