|
hackbunny posted:I was a reactos developer in 2001-2010 windows is already free so why does the world need a poorly executed copy of win2k
|
#
?
Nov 6, 2014 10:22
|
|
|
|
| # ? Apr 26, 2024 21:26 |
|
|
angry_keebler posted:windows is already free actually it is neither gratis nor libre. you see there's a thing called the microsoft tax which
|
|
#
?
Nov 6, 2014 10:35
|
|
|
this thread is great I would like to contribute more but I am legally barred from doing so,
|
|
#
?
Nov 6, 2014 11:08
|
|
|
Why are the Win32 APIs are so horrible? Like, even basics like naming scheme, how did something like SelectObject ever pass through as a global method? For a drawing API? Did MS not understand basic namespacing prefixes?
|
|
#
?
Nov 6, 2014 11:10
|
|
|
the stupid personal questions first:power botton posted:whats your native language. mine is python. C++  pram posted:how did it feel to waste a decade of your life? an accomplishment of shadowhawkian proportions not a total waste, it got me a job and a pretty unique idea for my bachelor's dissertation (mandatory access control on windows), but I'm happy I left, it was exactly the soul-draining experience you imagine it to be MALE SHOEGAZE posted:what are you doing now? voip stuff on iPhone and soon BlackBerry 10; some grails; some C to customize/unfuck Asterisk (= we make a secure messaging application). nothing that looks cool on a resume but it's making me a much better programmer  echinopsis posted:thanks for posting an OP I gess  angry_keebler posted:windows is already free it was the natural progression of my obsession with customizing Windows 98 (more on that later). I imagine it was the same for a lot of the other ReactOS developers. we had the true FOSS believers and Micro$oft haters but our best developers all use ReactOS as the methadone to Windows heroin eschaton posted:why? because I'm terminally uncool and got obsessed with customizing Windows 98 way back in 1999. I had all sorts of extra toolbars, launchers, tray apps, etc. I learned HTML and Javascript to customize my Active Desktop background and personal folder. back then, folder views were HTML views, the files were shown in an embedded ActiveX control, video previews in an embedded Windows Media Player ActiveX, etc. example stolen from an image search:  see that the window is split in two? title and description on the left, item list on the right. it's all HTML and the item list is a literal ActiveX embedded in the page with <object>. I think one of my very first customizations was replacing the four-color line below the folder title with rainbow_divider.gif. the turning point was probably setting per-folder icons, though, which Windows 98 made possible but incredibly hard. I finally had my victory by manually creating a new folder class (I think I copied the recycle bin as a template and tweaked the CLSID to make it unique) and desktop.ini magic it became an addiction. I would try all vaguely interesting dll exports with rundll32. I was one of the idiots who ran all the exes in %windir% and system32 one after another, forcing Microsoft to make sure they wouldn't do dangerous things when launched without arguments. I read all DOS documentation included in Windows 98, learned how to load ansi.sys and print colored text to the console; made a colored ascii art boot logo for autoexec.bat, so big I had to learn how to set 80x50 mode to fit it all I learned about Windows 98's registry backup program and how to run it automatically at startup; I never had to reinstall a broken Windows, I just rebooted in DOS mode and restored a recent registry backup. I won't blame you if you never heard of it, it was pretty well-hidden and I only found it by running all .exes, reading all .txts and comments in all .inis. it was also an interesting program, a rare example of hybrid DOS-Windows program: you may already know that Windows PE executables are in COFF format, prefixed with a DOS executable that normally is just a stub that prints "This program requires Windows", but can be any DOS program. the registry backup program was designed to backup non-interactively in Windows mode, and interactively restore in DOS mode (it even had a visual, text mode interface to select which backup to restore). another notable DOS-Windows hybrid was regedit.exe, but with opposite division of responsibilities: in Windows it was an interactive GUI, but you could run it from DOS as a non-interactive command line editor. scandisk.exe too, but again with a cool DOS UI and a lame progress bar in Windows the most extreme example of DOS-Windows hybrids were programs where the DOS executable was an extender that, other than protected mode (32 bit addressing with virtual memory), implemented a PE loader and Win32 API, so you ran the same identical code on DOS and Windows. extenders would typically identify themselves with a dummy function exported from their kernel32.dll (e.g. IsTNT, Borland32, etc.), and by running old enough programs under dependency walker's profile, you'll see them looking for those dummy functions with GetProcAddress. the check for kernel32!IsTNT was actually in the Microsoft C runtime library startup code for a while (it was used to force initialization of the C runtime in text mode, regardless of the main executable's declared subsystem), and ended up in several Windows executables. I don't know anything about Borland's extender, other than it had to exist at some time because all executables compiled with C++Builder (the horror, the horror) would look for kernel32!Borland32 at startup at least one extender (DJGPP) implemented a UNIX environment instead, which was actually good enough to run most of the GNU core tools and before Cygwin was the UNIX environment for Windows (before MinGW existed, the ReactOS build system ran on DJGPP. this is ancient history though, when I joined the project, only the boot loader was still built with DJGPP)
|
|
#
?
Nov 6, 2014 11:17
|
|
|
never stop posting
|
|
#
?
Nov 6, 2014 11:23
|
|
|
page two  chmods please posted:how the hell does IDispatch work? does it artisinally handcraft each call into an implementation? all i know is that there's voodoo with the typelib and the C++ vtable and afaik a giant black box in the middle technically? it doesn't need to. you totally can decode the arguments to IDispatch::Invoke manually and call the implementation, or even inline the implementation in IDispatch::Invoke (my god never do this). you can also totally implement ITypeInfo manually. if you are writing an OLE-compatible language (like say, .NET CLI) that stores type information in a format that isn't type libraries (say, .NET metadata), in fact, that's exactly what you'll have to do if the question is how the hell you're supposed to implement all of that, it's easy, OLE exports default implementations CreateStdDispatch and DispInvoke. these don't expose the full insanity of IDispatch, and limit you to implementing a single so-called dual interface: an interface that can both be used directly, with QueryInterface and compile-time code to look up methods from the vtable and direct invocations (this is called "early binding"), or dynamically, through IDispatch::Invoke ("late binding"). DispInvoke does exactly what you think it does, and it looks up the method implementation (i.e. raw function pointer) from the vtable of the early-bound interface. the calling convention (how registers and stack are used in passing arguments and receiving outputs), argument types, argument names in case the argument are set non-positionally (you could do this in Visual Basic), etc. all come from the ITypeInfo some objects implement dispinterfaces only, where the methods are listed in the type library with all the correct argument types etc. but can only be invoked through IDispatch::Invoke (hello Visual Studio automation, and gently caress you too). these are an incredible, massive pain to call from C++ as you literally have to build arrays of VARIANTs and stuff arguments in them. the Visual C++ compiler has a poorly documented extension where #import <typelibrary> automatically generates C++ stubs for all the interfaces in the type library (these include type-safe stubs for dispinterfaces), plus goodies like a smart pointer class for COM interfaces and C++ wrappers for VARIANT and BSTR, and an exception class that wraps HRESULTs. if you're curious about the dispinvoke stubs: they are based on a varargs function (undocumented, sources not included in the C runtime sources) that takes a "format string" of argument types (actually an array of USHORTs encoded as a wide string IIRC) followed by the arguments themselves witness the joy of calling dispinterfaces from C++ without any help from external libraries or stub generators (old build tool I wrote for ReactOS, long deleted, thank god) chmods please posted:...odds that the office team rolled their own implementation? pretty high actually! vba in particular, other than being a language with support for OLE and dynamic typing (therefore supposed to implement IDispatch without aid from the default implementation), does a lot of insane stuff with binary code (for example something they call "metamorphic objects": polymorphic objects that can get their vtable changed at runtime). it was cited as the reason office for x86 MacOS wouldn't have VBA: they had horrible hacks that worked with Visual C++ on x86 Windows and PowerBuilder on PowerPC MacOS, and no intention of creating a third set of hacks
|
|
#
?
Nov 6, 2014 12:26
|
|
|
echinopsis posted:never Seriously, all of your effort posts are a fascinating look into the world of the windows internals from someone who knows a lot about it, but remains dispassionately objective.
|
|
#
?
Nov 6, 2014 14:19
|
|
|
C++ reppin Since there seems to be a reduced level of shame for using windows in this thread I have a question. Around summer of 2012, all of my windows (7) machines slowed down to a crawl no matter what I did to speed them up. The word I got was that Microsoft(and others) started encrypting intra-process communications within windows to thwart government hacking attempts. I solved the problem on my home machine by throwing money at it (SSD and windows 8) but I have little control over my work machine. Everything else, including my ipad, is a flavor of unix. Are the reports of Intra-process encryption true and if so how can I shut them off?
|
|
#
?
Nov 6, 2014 14:30
|
|
|
Volmarias posted:someone who knows a lot about it, but remains dispassionately objective. cool, the least yospos thing ever
|
|
#
?
Nov 6, 2014 14:49
|
|
|
jonny stop making GBS threads up this thread
|
|
#
?
Nov 6, 2014 14:51
|
|
|
echinopsis posted:never
|
|
#
?
Nov 6, 2014 14:57
|
|
|
how much of reactos is still based on the stolen win 2000 source code
|
|
#
?
Nov 6, 2014 14:58
|
|
|
Bloody posted:jonny stop making GBS threads up this thread lol ok ok
|
|
#
?
Nov 6, 2014 15:00
|
|
|
Last Chance posted:how much of reactos is still based on the stolen win 2000 source code none has ever been. you can tell by how terrible the reactos code is. a few of us reverse engineered a lot though. one of my first successes was reverse engineering OutputDebugStringA aka the dbgview protocol
|
|
#
?
Nov 6, 2014 15:04
|
|
|
Jonny 290 posted:cool, the least yospos thing ever yospos is more than funny computer
|
|
#
?
Nov 6, 2014 15:18
|
|
|
Neil McCauley posted:Are the reports of Intra-process encryption true and if so how can I shut them off? I'm gonna take this one, op no
|
|
#
?
Nov 6, 2014 15:19
|
|
|
not at all
|
|
#
?
Nov 6, 2014 15:20
|
|
|
i read the posts in the op from what i can understand, they were good
|
|
#
?
Nov 6, 2014 17:05
|
|
|
what's the most cringeworthy thing you've ever seen gazing into the abyss that is microsoft software?
|
|
#
?
Nov 6, 2014 17:09
|
|
|
carry on then posted:why is command prompt so, command prompty i guess it all goes back to a terrible, terrible architectural choice they made way back in Windows NT 3.1 Win32 consoles are implemented in user mode. god knows why simple, safe consoles are a user mode thing, while a ton of badly written GUI poo poo was violently forced down kernel mode's throat, but they probably hoped that text consoles were going to be a fad? nevermind. this alone wouldn't be an issue, in fact if anything it would make providing multiple implementations of console windows very easy, but they had to double down on the awful, and make console windows run in the user-mode part of the win32 subsystem (basesrv.dll), which runs in a hyper-privileged process, csrss.exe. how privileged?
now take this incredibly sensitive process, and make it implement an interactive user interface they probably realized it was a bad idea when they added support for CJK languages. Chinese, Japanese and Korean need a way to enter a minimum of 24 unique letters - for Korean hangul - up to several thousand with a standard PC keyboard. this is impossible without some kind of software editor (even hangul's mere 24 unique letters, because they cannot appear separately, between 2 and 5 of them have to be arranged in a grid to spell a syllable). this editor is called IME (Input Method Editor), and it can be pretty complex (for example the Windows IME for Japanese has voice and handwriting recognition; both the Japanese and the Chinese IMEs have a built-in dictionary to disambiguate homophones; etc.), not to mention there can be multiple IMEs for a single language (I think Chinese has three IMEs) well. console windows are like "gently caress IMEs", and if you activate an IME (they are implemented as DLLs), it's run in a separate host process (conime.exe IIRC). I never managed to make this work because apparently you only get full CJK support (including backslashes showing up as yen signs in Japanese) if your system language is CJK, but I know it has to work roughly like that. there also is a device driver to make Japanese work in full-screen mode too (VGA BIOS obviously doesn't support Japanese), I think maybe it emulates NEC PC-98 graphics on the IBM PC architecture, but again, I never could fool Windows into running it I'm seriously digressing. back to console windows: they run in a critical ultra-privileged system process which doesn't load third party code, so forget hooks, window subclassing or even just visual styles. IMEs are run out of process. no toolbars, status bars, etc. because they're a Common Controls thing, which has a lot of undesireable dependencies; so you get console windows with even fewer features than MS-DOS consoles in Windows 98. drag-drop only works because it uses an ancient pre-shell32 protocol (CF_HDROP) originally designed for File Manager. no printing because drawing on printer device contexts loads printer drivers in your process, and we abhor third party code. you can see how a UI can stagnate under conditions like these. most people will never realize that Pause|Break pauses console output, or that F8 searches backwards in the input history, F1 repeats the last input line character by character, etc. because the UI is so barebones and doesn't even have state indicators. let's not even talk about features like macros, if anyone knows about them it's only because they were used to doskey.exe in MS-DOS and accidentally used the old commands and key bindings by force of habit (or because, like me, they looked inside the batch files that set up the device driver build environment) funny thing about the console window settings, if you were wondering: it's actually a control panel applet, the same you could once find in the control panel to set the defaults for all console windows. since it's a complex UI for super-special system process standards (for one, the tabbed dialog comes from common controls), the Win32 subsystem injects a thread in one of the processes attached to the console (!) to load and run it, which is incredibly rude, I know, but that's life, and also the easiest way for the settings applet to gain access to the existing console window (also the only way before Windows XP introduced AttachConsole) as I mentioned before, Vista introduced strong UI isolation, based on mandatory integrity levels. console windows, coming from a Very Special process, were given the highest integrity level possible, to protect them from any future, theoretical shatter attacks. otherwise this didn't fix any of the long-standing UI issues, in fact it further degraded usability by breaking drag&drop (no-write-up rule: can't write high-integrity state from a lower integrity level). in Windows 7 they finally moved console windows to a dedicated, unprivileged program, at the very least fixing visual styles, the drag&drop regression, and probably making it unnecessary to inject threads to bring up the settings window. it's still impossible to replace them with your own implementation (like a better UI, or holy grail features like translating console output to terminal escapes that can be serialized to a telnet/ssh/serial connection), but there's hope now that it may be doable within the decade. the reason I know so much about consoles, in fact, is that I made an abortive attempt way back in 2004 to move the console API to a kernel mode driver with both client and server ends, but got lost in minutiae first (like how many bits of data can I stuff without indirection in a single DeviceIoControl call if I use unbuffered I/O, pack two 16 bit values in each pointer argument and return an arbitrary value in the output? jesus, talk about premature optimization) and personal issues later, and now I don't have the slightest idea where I even put that code why were things so hosed for so long? to the point that the UI was objectively inferior to its 16 bit predecessors? I guess because Microsoft never believed in the command line as a first class UI until PowerShell carry on then posted:ie any insight as to why being able to select lines instead of regions debuts 13 years after windows stops being based on dos as an ~*~experiement~*~ oh wow, they finally implemented it then? baby steps I guess I think it was never done before for "efficiency", i.e. the console output buffer would only contain UTF-16 units and cell attributes, and any control characters were interpreted and discarded. so at the end of the line you didn't have a line ending, just spaces until the last column, because "lines" didn't exist, only a 2D grid of UTF-16 units (same reason you can only resize console buffers from the settings window and not interactively: by making the window narrower, lines are truncated, not rewrapped). console windows are full of "efficiency" hacks, like how their window class has the CS_OWNDC style (in short a really old school way to make your window double-buffered). it's all kind of undone by the roundtrips to csrss.exe and back and text-mode output on Windows is notoriously slow, so who the hell knows what they had in mind
|
|
#
?
Nov 6, 2014 17:15
|
|
because a BSOD is instant, while when you kill csrss.exe you can e.g. hear the disks flushing. little known fact: before Windows XP, crashing on termination of a critical process wasn't a kernel feature; instead, the startup process (smss.exe) would wait for the termination of csrss.exe and winlogon.exe, and hit you with a hard error if it ever returned from the wait. you'll notice a flaw: nobody watches the watcher (kernel don't gaf). you could totally kill smss.exe and then csrss.exe without a BSOD. back then, the debugging APIs were implemented in user mode for some loving reason, and for an even more inexplicable reason they were a RPC API and smss.exe was the server end, so killing smss.exe would have no visible effect, except breaking debugging until a reboot
|
5
|
|
#
?
Nov 6, 2014 17:29
|
|
|
this thread reminds me in a good way of "the old new thing" only even nerdier
|
|
#
?
Nov 6, 2014 17:36
|
|
|
is it true that excel is compiled with a custom compiler that isn't used for anything else
|
|
#
?
Nov 6, 2014 17:54
|
|
|
this is a cool thread
|
|
#
?
Nov 6, 2014 18:00
|
|
|
is it true the registry was intentionally devised as inefficient and a way for systems to collect junk that will slow them down over time?
|
|
#
?
Nov 6, 2014 18:11
|
|
|
nielsm posted:is it true the registry was intentionally devised as inefficient and a way for systems to collect junk that will slow them down over time? yes, to make it harder for the government to hack you. lmao
|
|
#
?
Nov 6, 2014 18:13
|
|
|
what the gently caress is "intra-process communication" anyway
|
|
#
?
Nov 6, 2014 18:14
|
|
|
i do not understand much of what you say but it is very insightful and intelligent windows internals thread is the new nintendo game making thread and this makes me happy to read this yospos
|
|
#
?
Nov 6, 2014 18:17
|
|
|
Heresiarch posted:this thread reminds me in a good way of "the old new thing" only even nerdier I promise I won't start posting what I dreamed last night
|
|
#
?
Nov 6, 2014 18:19
|
|
|
hackbunny posted:it all goes back to a terrible, terrible architectural choice they made way back in Windows NT 3.1  5
|
|
#
?
Nov 6, 2014 18:24
|
|
|
flakeloaf posted:i do not understand much of what you say but it is very insightful and intelligent whoa was there one of those i was unaware of?
|
|
#
?
Nov 6, 2014 18:39
|
|
|
Also, I'm confused. If IMEs are run out of process and all they're allowed to do is inject key events, what's wrong with the terminal window here? Doesn't it just receive key events from its mainloop and act on them?
|
|
#
?
Nov 6, 2014 18:40
|
|
|
Suspicious Dish posted:whoa was there one of those i was unaware of? yeah I want a link to this
|
|
#
?
Nov 6, 2014 18:41
|
|
|
Suspicious Dish posted:whoa was there one of those i was unaware of? iirc it was mostly just links to good poo poo offsite http://forums.somethingawful.com/showthread.php?threadid=3555611
|
|
#
?
Nov 6, 2014 18:42
|
|
|
hackbunny posted:... 
|
|
#
?
Nov 6, 2014 18:43
|
|
|
Werthog 95 posted:iirc it was mostly just links to good poo poo offsite http://forums.somethingawful.com/showthread.php?threadid=3555611 Oh yeah that thread. I was hoping it was more poo poo like my N64/GC/Wii posting.
|
|
#
?
Nov 6, 2014 18:44
|
|
|
Suspicious Dish posted:Oh yeah that thread. I was hoping it was more poo poo like my N64/GC/Wii posting. nah you should make a thread
|
|
#
?
Nov 6, 2014 18:45
|
|
|
Suspicious Dish posted:Also, I'm confused. If IMEs are run out of process and all they're allowed to do is inject key events, what's wrong with the terminal window here? Doesn't it just receive key events from its mainloop and act on them? if I remember correctly, IMEs are DLLs (it's easy to check, look for .ime files and see if they are DLLs. IIRC). I assume they're loaded in-process because where else? there is no standard out of process host for IMEs that I know of. conime.exe is how console windows load them out of process (again, I think. I never managed to get IMEs to work in console windows) the most complex IMEs (like the Japanese IME) do have a resident process, but that's just good engineering I can check personally later when I'm at home, here at work we all use macs also IMEs don't really post to the message queue, instead you query them for input with the IMM (Input Method Manager) API. I don't remember the exact details, I studied this stuff a long time ago for a keylogger. most of the documentation isn't even in the Windows SDK, IMEs are considered drivers and documented (barely) in the DDK. then there's TSF (Text Services Framework) where you share your editor's buffer with a "text service" so that text can flow both ways, so text services can be IMEs but also things like spell checkers. but TSF is a transplant from Microsoft Office and it shows, it's really sloppy work (ugly non native UI, COM interfaces that violate the ABI and can only be used from C++) and a huge insanely complex API
|
|
#
?
Nov 6, 2014 19:06
|
|
|
|
| # ? Apr 26, 2024 21:26 |
|
|
Werthog 95 posted:nah I'll do that today.
|
|
#
?
Nov 6, 2014 19:13
|
|