Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Worst API Ever Made?

mollyrocket.com

Post reply on HN
Print view View original

71–80 of 82 posts

Re: The Worst API Ever Made?

#71

Post by asveikau »

angersock wrote: post #63
dllthomas wrote: post #62

Earlier quoted context omitted.

I think the complaint was about the cast to LPSTR at the end. typedef char* PSTR, *LPSTR; After the addition, you've already got a char * - casting to a char * again by another name is unnecessary.

So, at that point, it gets to be a little more philosophical, right? I err on the side of "Oh, the API requests this type (which I'll pretend I don't know is actually just a char*), so I will explicitly cast to that". At least that way it's clear in the future that there is some explicit changing of types going on if, say, LPSTR ever changes. Silent "Oh, well, we all know that it's really going to be a pointer here a…

PSTR and PWSTR have a size implicit in their name. They are not going to change. PTSTR (so far not talked about) happens to change based on a macro but I would not recommend using it in this century - it's easier to build all your Windows apps as utf-16 and pretend everything is PWSTR (could be a whole other topic).

It sounds more like you err on the side of inserting lots of pointer casts into the code without considering or very well understanding what the types mean, in order to "shut up compiler warnings" that might not even exist. This is pretty common but it is often a really good sign of someone who doesn't know what they are doing, they are fighting the compiler warnings in their own head instead of solving real problems. (It's really easy for a pointer cast to mask a bug too.)

Frivolous pointer casts are always suspicious. It's much better to let your compiler generate the warnings, listen to them and understand them, and in a lot of cases, fix issues without mindlessly putting in a cast.

Re: The Worst API Ever Made?

#72

Post by angersock »

asveikau wrote: post #71
angersock wrote: post #63

Earlier quoted context omitted.

So, at that point, it gets to be a little more philosophical, right? I err on the side of "Oh, the API requests this type (which I'll pretend I don't know is actually just a char*), so I will explicitly cast to that". At least that way it's clear in the future that there is some explicit changing of types going on if, say, LPSTR ever changes. Silent "Oh, well, we all know that it's really going to be a pointer here a…

PSTR and PWSTR have a size implicit in their name. They are not going to change. PTSTR (so far not talked about) happens to change based on a macro but I would not recommend using it in this century - it's easier to build all your Windows apps as utf-16 and pretend everything is PWSTR (could be a whole other topic). It sounds more like you err on the side of inserting lots of pointer casts into the code without consi…

Whatever dude. Go on living in your magical bubble (in Redmond, perhaps...?). You've seen the arguments here against why your earlier analysis is wrong, and are hellbent on insisting that writing more explicit code is not a good idea because you're such an elite h4x0r.

With any luck I won't have the pleasure of sharing a codebase with you.

EDIT:

Also, UTF-16 is bad and you should feel bad.

Re: The Worst API Ever Made?

#73

Post by angersock »

dllthomas wrote: post #64
angersock wrote: post #63

Earlier quoted context omitted.

So, at that point, it gets to be a little more philosophical, right? I err on the side of "Oh, the API requests this type (which I'll pretend I don't know is actually just a char*), so I will explicitly cast to that". At least that way it's clear in the future that there is some explicit changing of types going on if, say, LPSTR ever changes. Silent "Oh, well, we all know that it's really going to be a pointer here a…

Right. For the record, I wasn't criticizing - I mostly agree with the side you're erring on here - I was just trying to clarify the criticism.

Gotcha, thanks. :)

Re: The Worst API Ever Made?

#74

Post by asveikau »

angersock wrote: post #72
asveikau wrote: post #71

Earlier quoted context omitted.

PSTR and PWSTR have a size implicit in their name. They are not going to change. PTSTR (so far not talked about) happens to change based on a macro but I would not recommend using it in this century - it's easier to build all your Windows apps as utf-16 and pretend everything is PWSTR (could be a whole other topic). It sounds more like you err on the side of inserting lots of pointer casts into the code without consi…

Whatever dude. Go on living in your magical bubble (in Redmond, perhaps...?). You've seen the arguments here against why your earlier analysis is wrong, and are hellbent on insisting that writing more explicit code is not a good idea because you're such an elite h4x0r. With any luck I won't have the pleasure of sharing a codebase with you. EDIT: Also, UTF-16 is bad and you should feel bad.

They made a big bet on 16 bit chars before utf-8 existed. Lots of stuff from the same time period stuck with the same choice (java is one example). I am not a fan or opponent of utf-16, utf-8 does work well, but in many places a larger char type is a reality. In Windows it's the only way that makes sense, by the time you get to a syscall you need 16 bit strings and support for anything else without conversion is considered legacy.

I'm not even saying this is the only way to structure a code base or that I'm unwilling or haven't seen or worked with something else. I'm talking about what the sane conventions for a Windows app would be. When in Rome, and all that. I would not advocate utf-16 on Unix (even if that's what millions of people using say Java end up getting).

Re: The Worst API Ever Made?

#75

Post by StavrosK »

zyb09 wrote: post #10
kabdib wrote: post #4

Earlier quoted context omitted.

Well, the API in question (which I've used, and it was indeed an unpleasant experience) might not be solving something trivial , but it's certainly not well designed. My all-time worse API is SetupAPI, which despite its name is how you get access to USB devices on Windows. It's . . . pretty miserable. Runner-up is the COM-based stuff that manages the Windows firewall, which is not well specified and has 'interesting'…

My award goes to Extended MAPI. It took me weeks of trial and error just to read and send email messages through an Exchange Server. I remember people were selling 3rd party wrappers for the API, because it was so horrible.

Man, and my idea of an ugly API is urllib2...

Re: The Worst API Ever Made?

#76

Post by asveikau »

anon4 wrote: post #54
asveikau wrote: post #46

Poster has not worked very deeply with Win32, is unaware of its conventions. Film at 11. For example: > Yes, that’s right, every user of the Event Tracing for Windows API has to do the arithmetic and layout of the packed structure format themselves. These represent very common idioms in Windows. One common idiom is about binary compatibility. Microsoft can change the length of the structure in a future rev of the SDK…

Yes, that's frequently done in win32 land, but in this case, I'd argue the following should have been done 1) Why provide a copy of the parameter at the end of a struct? 2) How will you ever expand that struct given the fact that you put a variably-sized member at the end? 3) Why doesn't the current version of the header come with a char[] SessionName; member as last member, so it's at least halfway convenient? 4) No…

> No seriously - why is it copied in at the end and not a pointer?

Consider where you have seen similar patterns in the Unix world. The obvious one would be they intend to pass the buffer to kernel mode and a structure with lots of pointers inside will be a pain in the ass to pass over and validate.

A flat buffer with a couple of offsets works better for that. Copy over the whole blob, check a few lengths. Generate your EFAULT errors in a single place. Better than following lots of user mode pointers.

Re: The Worst API Ever Made?

#77

Post by amaks »

A funny anecdote on the topic. When I worked in WinFS team, folks tried to add new flags in CreateFile API. Turns out, all 32 bits in dwFlagsAndAttributes were already taken, including the hidden usages inside the Win32 subsystem implementation.

Re: The Worst API Ever Made?

#78

Post by Hakeashar »

Someone1234 wrote: post #58
pwilson_gorge wrote: post #44

I offer a simple API decision which has condemned generations of programmers to useless toil. The decision in .Net to not map database NULL to programming language null. Perhaps there was some higher level philosophical distinction being drawn which mere mortals are not capable of understanding.

> The decision in .Net to not map database NULL to programming language null. What specific API in the .Net framework does this (or doesn't do this)? Definitely hasn't been my experience but I am using Entity Framework so... It goes so far as to mark null-able database types as (bool?) (nullable bool) which is super helpful and you can use == null for comparisons.

ADO.NET uses DBNull: http://msdn.microsoft.com/en-us/library/system.dbnull(v=vs.1...

There's one valid (if obscure) use case for it, other than that it is pretty much redundant: http://stackoverflow.com/q/4488727/1180426

All modern (micro)ORMs, even if they're just a thin wrapper over ADO.NET like Dapper, work just fine with regular nulls.

Re: The Worst API Ever Made?

#79

Post by Dylan16807 »

wfunction wrote: post #3

"The API is simple because the problem it’s solving is trivial." I beg to differ -- as ridiculous as the API interface may be, the problem it's solving is most certainly not even close to being trivial. High-performance logging for something as low-level as the thread scheduler is not something you can write in your sleep.

The API is not the service. The service is solving a hard problem. The API is reading rather simple data from the service in batches. The API's problem is a trivial one.

Re: The Worst API Ever Made?

#80

Post by __david__ »

wfunction wrote: post #35
__david__ wrote: post #33

Earlier quoted context omitted.

> What is the system supposed to do here? There are a million possibilities… No, there are two: You dump old data or you dump new data. Everything else should be up to the user code. It's really not as difficult as you are making it out to be. There's certainly no excuse for a ridiculous API as described in the article.

Huh? If you dump data you miss events. Imagine if Process Monitor decided to suddenly dump half of the system calls it monitored. Wouldn't that be ridiculous? For a general event-tracing system, there have to be more options provided. Maybe it wouldn't matter so much for context-switching per se, but for a ton of other types of events you really need to track each and every event.

Yes, you miss events. But if you try to make build the kitchen sink into your low-level logging system then it ceases to be low level. If your logging system allocates memory then how can you log events from your VM subsystem? If your logging system logs to the disk, then how do you log ATA events? It becomes recursive and intractable.

The solution is to make your main interface a very simple pre-allocated ring buffer and have userspace take that and do what they please with it (as fast as it can so things don't overflow).

There is always a point at which your logging system can't keep up. At the kernel level you decide which side of the ring buffer to drop (new data or old) and at the userspace level you decide whether to drop things at all or whether to grind the system to a halt with memory, disk, or network usage.

Post reply on HN